Skepsis am neuen Standard

[Nexus]

Shade Of Mine schrieb:

Es gibt ganze Sprachen die streng typisiert sind und man nie einen typen angeben muss. absolut top. der typ interessiert nämlich sowieso nie.

Das sagst du jetzt so. Ich bin aber der Meinung, als Programmierer identifiziert man wichtige Informationen mit dem Typen. Ich kann mir unter std::vector<T, std::allocator<T> > einigermassen etwas vorstellen, und zwar mehr als nur ein Container von T. Klar ist es okay, bis zu einem gewissen Grad zu abstrahieren, das hat man ja jetzt bereits mit typedef .

Aber es gibt auch eine gewisse Sicherheit, den Typen zu kennen - denn die Funktionalität unterscheidet sich meistens deutlich, auch wenn die Schnittstelle mehr oder weniger die gleiche ist. Ich habe vor, im neuen Standard soweit wie möglich auf auto und decltype verzichten, sofern die Übersicht nicht stark darunter leidet.

audacia schrieb:

Boost.Regex beispielsweise ist vollständig in Headerdateien implementiert

Nein, Boost.Regex führt Bibliotheken mit.

audacia schrieb:

Natürlich hat das was damit zu tun. Es bläht den Code in den eingebundenen Headerateien, in meinen Übersetzungsmodulen und oft auch in der fertigen Executable auf.
Außerdem geht es ja nicht spezifisch um Boost.Regex (wie "z.B." eigentlich ausdrückt). Es gibt jede Menge Bibliotheken nach diesem Prinzip. C++ und die Standardbibliothek begünstigen solche Bibliotheken nachdrücklich.

Templates haben eben auch ihren Preis, das hat man dafür in anderen Sprachen nicht. Man muss sie ja nicht exzessiv anwenden, aber sie verleihen einem enorme Möglichkeiten. Dafür bin ich gerne bereit, Kompromisse beim Kompilieren einzugehen. Und wie export gezeigt hat, scheint die Problematik nicht allzu trivial zu sein - was sollte also deiner Meinung nach geändert werden?

[audacia]

Nexus schrieb:

audacia schrieb:

Boost.Regex beispielsweise ist vollständig in Headerdateien implementiert

Nein, Boost.Regex führt Bibliotheken mit.

Ah, tatsächlich. Dann muß ich meine Äußerung natürlich korrigieren: 80% von Boost.Regex befinden sich in Headerdateien.

Nexus schrieb:

Templates haben eben auch ihren Preis, das hat man dafür in anderen Sprachen nicht. Man muss sie ja nicht exzessiv anwenden

Gleiches Argument, gleicher Widerspruch: doch, man muß, weil andere das auch tun, und in der Praxis hast du gewöhnlich nicht den Luxus, nur mit selbstgeschriebenem Code arbeiten zu müssen.

Nexus schrieb:

was sollte also deiner Meinung nach geändert werden?

Templates sind sehr nützlich und haben ihre Berechtigung. Die meisten Anwendungsfälle für Templates hätten sich allerdings mit gut spezifizierten Generics genauso lösen lassen. Und sobald man Generics verwendet, läßt sich export wunderbar implementieren. Man hätte der Sprache eine Menge erspart, wenn man zusätzlich zu Templates so etwas wie Restricted Templates oder eben Generics eingeführt hätte.

[Nexus]

audacia schrieb:

Gleiches Argument, gleicher Widerspruch: doch, man muß, weil andere das auch tun, und in der Praxis hast du gewöhnlich nicht den Luxus, nur mit selbstgeschriebenem Code arbeiten zu müssen.

Das kann gut sein, dazu kenne ich mich ehrlich gesagt zu wenig im professionellen Bereich aus. Aber stellen Templates wirklich ein solches Problem dar? Man kann Instanziierungen in andere Module auslagern und auch vorkompilierte Header helfen enorm bei der Kompilierzeit-Verkürzung. Oder ist die grössere Binary das Hauptproblem? Oder alles zusammen?

Nexus schrieb:

Man hätte der Sprache eine Menge erspart, wenn man zusätzlich zu Templates so etwas wie Restricted Templates oder eben Generics eingeführt hätte.

Aber so was kann man sich ja eigentlich selber basteln, zum Beispiel über void* . Klar ist das nicht der schönste Weg, aber wenigstens etwas in die Richtung. Ich verstehe aber, dass das aufgrund der existierenden Templates, die auch meistens angewandt werden, nicht wirklich eine Alternative darstellt.

[Shade Of Mine]

Nexus schrieb:

Ich bin aber der Meinung, als Programmierer identifiziert man wichtige Informationen mit dem Typen. Ich kann mir unter std::vector<T, std::allocator<T> > einigermassen etwas vorstellen, und zwar mehr als nur ein Container von T. Klar ist es okay, bis zu einem gewissen Grad zu abstrahieren, das hat man ja jetzt bereits mit typedef .

Warum ist es wichtig ob es ein vector<int, std::allocator> oder ein vector<int, my_alloc> oder ein my_vec<int> ist?

Aber es gibt auch eine gewisse Sicherheit, den Typen zu kennen - denn die Funktionalität unterscheidet sich meistens deutlich, auch wenn die Schnittstelle mehr oder weniger die gleiche ist. Ich habe vor, im neuen Standard soweit wie möglich auf auto und decltype verzichten, sofern die Übersicht nicht stark darunter leidet.

Es ist stark typisiert. du kannst also nicht ein vec.run_forrest_run() machen.

auto iter = v.begin();

ist zB super praktisch. wozu muss ich hier extra den typen angeben. mich interessieren die allocatoren doch garnicht, ich will nen iterator haben.

und das ist fast überall so. typen händisch angeben wenn es eh keine wahl gibt, ist sinnloser mehraufwand. es ist ja nicht so als ob es andere typen wären - auto reduziert den wartungsaufwand enorm. da du plötzlich nicht mehr dauernd typedef verwenden musst - sondern einfach auto nimmst.

wenn du mal länger mit type inference gearbeitet hast willst du es nicht mehr missen.

[knivil]

Templates sind Generics. Und den rigerosen Templateeinsatz bei Boost finde ich auch nicht toll. Desweiteren habe ich google benutzt, wurde daraus aber nicht recht schlau.Und zum Thema Closures: das "Feature" hat schon C (und wahrscheinlich jede andere Programmiersprache), aber du erkennst sie vielleicht nicht als Closure.

[audacia]

Nexus schrieb:

Ich verstehe aber, dass das aufgrund der existierenden Templates, die auch meistens angewandt werden, nicht wirklich eine Alternative darstellt.

Das ist der Punkt.

[audacia]

knivil schrieb:

Templates sind Generics.

Nein.

knivil schrieb:

Und zum Thema Closures: das "Feature" hat schon C

Nein.

Wie kommst du dazu, anderen das Verbreiten von Halbwahrheiten anzulasten?

[knivil]

Fuer dich Wikipedia: http://de.wikipedia.org/wiki/Generischer_Typ und http://de.wikipedia.org/wiki/Closure . Objekte koennen Closures sein, Closures koennen Objekte sein.

Wie kommst du dazu, anderen das Verbreiten von Halbwahrheiten anzulasten?

Weil sie anscheinend dahinterstehende Konzepte nicht verstanden haben. Klar ist das Generics aus C# nicht vergleichbar mit denen aus C++, aber es sind doch beides Elemente der generischen Programmierung, Generics.

[Simon2]

Hi audacia,

ich will Dir gar nicht widersprechen, aber ich habe den Eindruck, dass hier einfach 2 Paradigmen aufeinanderstoßen: Compilezeit vs. Laufzeit.

Da schlägt sich C++ halt sehr eindeutig auf die Seite der Compilezeit (außer z.B. bei exceptione specifications, wo es mal wirklich sinnvoll gewesen wäre ). Je mehr man das Ziel verfolgt, möglichst alle Fehlerquellen bereits zur Compilezeit auszumerzen und das Ganze noch mit generischer Programmierung würzt, desto schwerer wird es einfach, dem Compiler den kompletten Quellcode vorzuenthalten .... mit allen Nachteilen wie: Zerbröselnde Linkzeit-Modularisierung, unzureichende Typinformation zur Laufzeit (wobei man die als "Gimmick" wohl trotzdem implementieren dürfte, es aber wohl eher nicht so wichtig ansieht), ...
Vielleicht haben sich die C++-Kommittee-ler auch einfach gedacht: "Wer das möchte, ist mit Java prima bedient."

Ich persönlich vermisse die "Compilerunabhängigkeit" (und sei es nur auf einer Plattform) am meisten; für jedes Produkt NxM-Matrizen an plattform- UND compiler(versions)abhängigen Libs gegeneinander abgleichen zu müssen, wird zur Sysiphusarbeit und oftmals absoluten Innovationsbremse...

Gruß,

Simon2.

[Nexus]

Shade Of Mine schrieb:

Warum ist es wichtig ob es ein vector<int, std::allocator> oder ein vector<int, my_alloc> oder ein my_vec<int> ist?

Ich habe jetzt eher im Vergleich zu std::list oder anderen Containern gemeint. Das Wissen über den Allokator kann zwar auch nie schaden, aber das ist leicht bei der Deklaration (oder beim Rückgabetypen einer Funktion) nachlesbar.

Shade Of Mine schrieb:

auto iter = v.begin();

ist zB super praktisch. wozu muss ich hier extra den typen angeben. mich interessieren die allocatoren doch garnicht, ich will nen iterator haben.

und das ist fast überall so. typen händisch angeben wenn es eh keine wahl gibt, ist sinnloser mehraufwand. es ist ja nicht so als ob es andere typen wären - auto reduziert den wartungsaufwand enorm. da du plötzlich nicht mehr dauernd typedef verwenden musst - sondern einfach auto nimmst.

Da hast du Recht, mit Iteratoren oder längeren Typen wie solchen aus Boost kann automatische Typerkennung wirklich sehr praktisch sein (hatte ich zwar früher bereits geschrieben, aber im letzten Post irgendwie verdrängt).

Aber schon beim begin() kann es zu Problemen führen, da man je nachdem einen const_iterator will... Oder?

Und eben befürchte ich, dass man schnell zur Übertreibung neigt, denn auto ist fast überall anwendbar, wo eine Initialisierung mit einem Ausdruck stattfindet.

auto x = 3;
auto pos = Object.GetPosition(); // Was ist jetzt pos? Vector<3, float> oder Vector<2, int>?
auto size = Blabla.GetSize();  // wie gross ist size? short? int? long? size_t?

Die Beispiele sind vielleicht etwas überspitzt, aber ich selber würde wahrscheinlich relativ schnell die Übersicht verlieren. Es fängt ja schon mit Dingen wie IntelliSense an, wo man sich nicht mehr viel Bezeichner merken muss. Mit auto bekommt man auch die Typen geschenkt. An manchen Orten ist die Abstraktion hilfreich, an anderen weniger...

knivil schrieb:

Fuer dich Wikipedia: http://de.wikipedia.org/wiki/Generischer_Typ

Hast du auch den Satz "Ein anderer Weg, den u.a. C++ geht, ist die Anwendung von Templates." gelesen?

[knivil]

Hast du auch den Satz "Ein anderer Weg, den u.a. C++ geht, ist die Anwendung von Templates." gelesen?

Soll ich dir auch den Artikel vorlesen: "Bei Programmiersprachen gibt es prinzipiell zwei Ansätze, generische Typen zu unterstützen ...". Und mit "ein anderer Weg" stellt einfach nur einen Gegensatz zur ersten Moeglichkeit dar. Ja und genau deswegen Halbwissen, weil aus nicht richtig Lesen und noch weniger Verstehen irgendwie 'ne Meinung entsteht, die einfach nur zum Himmel schreien ist.

[audacia]

knivil schrieb:

Fuer dich Wikipedia

Wikipedia-Links sind nicht gut geeignet, um zu kaschieren, daß du dich mit der Differentation von Templates und Generics noch nicht beschäftigt hast.

knivil schrieb:

Jedes Objekt kann man als Closure abstrahieren oder aber auch andersherum.

Der Unterschied zwischen der grundsätzlichen Möglichkeit und einer Sprachunterstützung ist dir bekannt?

Simon2 schrieb:

Vielleicht haben sich die C++-Kommittee-ler auch einfach gedacht: "Wer das möchte, ist mit Java prima bedient."

Den Eindruck habe ich auch

Simon2 schrieb:

Je mehr man das Ziel verfolgt, möglichst alle Fehlerquellen bereits zur Compilezeit auszumerzen und das Ganze noch mit generischer Programmierung würzt, desto schwerer wird es einfach, dem Compiler den kompletten Quellcode vorzuenthalten ....

Das stimmt schon, aber z.B. Generics sind ebenso typsicher wie Templates, können aber anders als diese in untypisiertem Zustand geparst werden. Dadurch ist dann auch ein export -Mechanismus gut machbar. (Praktischer Beweis: Delphi 2009. Das unterstützt Generics, die zur Übersetzungszeit instantiiert werden - sie sind demnach ebenso effizient wie Templates -, doch werden sie dennoch wie gewöhnliche Klassen geparst - was das Problem der nutzlosen Fehlermeldungen, das man in C++ durch Concepts angehen will, vermeidet.)

Simon2 schrieb:

Ich persönlich vermisse die "Compilerunabhängigkeit" (und sei es nur auf einer Plattform) am meisten; für jedes Produkt NxM-Matrizen an plattform- UND compiler(versions)abhängigen Libs gegeneinander abgleichen zu müssen, wird zur Sysiphusarbeit und oftmals absoluten Innovationsbremse...

So wünschenswert das wäre: auch hierfür ist es viel zu spät. An so etwas hätte man zu Anfang der Entwicklung denken müssen.

[Nexus]

Gut, auf Wikipedia werden Generics mit generischen Typen gleichgesetzt. Im Sprachgebrauch meint man mit Generics aber eher die Typen, wie sie z.B. in Java verwendet werden. Im englischen Wikipedia-Artikel werden die Begriffe zum Beispiel auch weniger verwaschen.

Ich hatte deinen Post zuerst auch so verstanden, als wolltest du Templates und Generics als identisch bezeichnen.

[knivil]

Nexus schrieb:

Gut, auf Wikipedia werden Generics mit generischen Typen gleichgesetzt. Im Sprachgebrauch meint man mit Generics aber eher die Typen, wie sie z.B. in Java verwendet werden. Im englischen Wikipedia-Artikel werden die Begriffe zum Beispiel auch weniger verwaschen.

Ich habe den englischen auch gelesen. Dort heisst es im Eingangsbeispiel: commonly called generics.

[Nexus]

knivil schrieb:

Ich habe den englischen auch gelesen. Dort heisst es im Eingangsbeispiel: commonly called generics.

Stimmt, hab ich übersehen. Wie dem auch sei, Wikipedia ist nicht der Weisheit letzter Schluss. Ich habe jedenfalls noch nie jemanden die C++-Templates Generics nennen hören, allzu verbreitet scheint der Begriff also nicht zu sein. Aber wenden wir uns lieber wieder dem Thema zu...

audacia schrieb:

Das stimmt schon, aber z.B. Generics sind ebenso typsicher wie Templates, können aber anders als diese in untypisiertem Zustand geparst werden. Dadurch ist dann auch ein export -Mechanismus gut machbar. (Praktischer Beweis: Delphi 2009. Das unterstützt Generics, die zur Übersetzungszeit instantiiert werden - sie sind demnach ebenso effizient wie Templates -, doch werden sie dennoch wie gewöhnliche Klassen geparst - was das Problem der nutzlosen Fehlermeldungen, das man in C++ durch Concepts angehen will, vermeidet.)

Wie kann die volle Typsicherheit in untypisiertem Zustand bewahrt werden? Das klingt auch so, als hätte sich das C++-Standardkomitee gar nichts überlegt.

[Simon2]

audacia schrieb:

...

Simon2 schrieb:

Je mehr man das Ziel verfolgt, möglichst alle Fehlerquellen bereits zur Compilezeit auszumerzen und das Ganze noch mit generischer Programmierung würzt, desto schwerer wird es einfach, dem Compiler den kompletten Quellcode vorzuenthalten ....

Das stimmt schon, aber z.B. Generics sind ebenso typsicher wie Templates, ...

Gleich vorweg: Mit Generics habe ich mich noch nicht beschäftigt und auch mit Delphi nicht.
Allerdings (oder vielleicht deswegen) fällt es mir schwer, mir vorzustellen, wie man das (vom Templateparameter abhängige) Verhalten eines Templates typsicher gestalten will, wenn man es nicht (noch) einmal mit diesem zusammen compiliert.

Wie gesagt: Kann an meiner Unwissenheit oder mangelnden Phantasie liegen, ist aber so.

Gruß,

Simon2.

[C++fan 2009]

C++-Progger, ein schrieb:

Warum tut das Standardkomitee eigentlich so als würde C++ in einer Luftblase existieren? Es wäre doch allen geholfen, wenn man C++ mit der realen Welt im Hinterkopf entwickeln würde, schließlich will man ja auch dort die Sprache einsetzen.

Man kann C++ sehr gut real einsetzen. Man braucht nicht jeden Quatsch verwenden, den es anbietet.

[Shade Of Mine]

Nexus schrieb:

Aber schon beim begin() kann es zu Problemen führen, da man je nachdem einen const_iterator will... Oder?

Um ehrlich zu sein: meistens ist mir das total egal.

Und eben befürchte ich, dass man schnell zur Übertreibung neigt, denn auto ist fast überall anwendbar, wo eine Initialisierung mit einem Ausdruck stattfindet.

Das finde ich zB super.

auto x = 3;
auto pos = Object.GetPosition(); // Was ist jetzt pos? Vector<3, float> oder Vector<2, int>?
auto size = Blabla.GetSize();  // wie gross ist size? short? int? long? size_t?

Warum ist es wichtig ob pos ein Vector<3, int> oder ein Vector<7, float> ist?
Und warum ist es wichtig welchen unsigned typen size hat? es ist groß genug die größe von Blabla zu beinhalten. wenn ich eine bestimmte größe haben will, dann gebe ich den typen selber an. aber meistens will ich das nicht. vorallem wenn templates im spiel sind.

typename vector_type::iterator i = v.begin();
typename vector_type::iterator e = v.end();
while(i!=e) {
  typename vector_type::value_type copy = *i;
  copy.foo();
  ++i;
}

*brr*

viel schöner:

for(auto i=v.begin(), e=v.end(); i!=e; ++i) {
  auto copy = *i;
}

Überall wo du mit templates zu tun hast wird der code soviel klarer durch auto.

vorallem wenn du plötzlich template factories hast:
auto func = create_expression<TypeList<foo, bar, baz, None>>();

Es fängt ja schon mit Dingen wie IntelliSense an, wo man sich nicht mehr viel Bezeichner merken muss. Mit auto bekommt man auch die Typen geschenkt. An manchen Orten ist die Abstraktion hilfreich, an anderen weniger...

Und wo ist das schlecht? Intellisense ist super weil ich mir nix merken muss und auto erspart mir wieder sinnlose information zu tippen.

[Shade Of Mine]

audacia schrieb:

(Praktischer Beweis: Delphi 2009. Das unterstützt Generics, die zur Übersetzungszeit instantiiert werden - sie sind demnach ebenso effizient wie Templates -, doch werden sie dennoch wie gewöhnliche Klassen geparst - was das Problem der nutzlosen Fehlermeldungen, das man in C++ durch Concepts angehen will, vermeidet.)

Ist in C++ nur wegen der fehlenden standardisierten ABI nicht möglich.

Deshalb tut man precompiled header verwenden um den kompilierungsaufwand zu reduzieren.

Aber ich kenne die Templates in Delphi nicht - habe nur sehr gemischtes darüber gehört. Kannst du deren funktionalität mal näher erklären?

[audacia]

Vorweg: Kompiliert wird eine generische Klasse erst, wenn sie mit einem konkreten Typen instantiiert wird. Geparst hingegen wird sie schon untypisiert. In den Moduldateien (bei Delphi sind das *.dcu-Dateien) wird dann der Parse-Tree abgelegt, in den bei der Instantiierung nur noch die tatsächlichen Typen injiziert werden müssen.

Nexus schrieb:

Wie kann die volle Typsicherheit in untypisiertem Zustand bewahrt werden?

Durch Typrestriktionen. Bei der Deklaration der generischen Klasse muß der Typ so beschränkt werden, daß zu dessen Übersetzungszeit bekannt ist, welche Operationen dieser Typ beherrscht. Dafür kannst du dann nicht mehr irgendwelche Methoden des Arguments aufrufen, die nicht durch die Typrestriktion explizit bekannt gemacht wurden:

template <class T>
    bool isEqual (T lhs, T rhs)
{ return lhs == rhs; } // geht nicht mit Generics

Wenn du aber eine entsprechende Typrestriktion angibst, kannst du so etwas auch mit Generics machen. Bei den Generics in .NET sähe das etwa so aus (Syntax ist Delphi für .NET, da ich nicht flüssig in C# bin):

type
  CompareHelper <T: IEquatable <T>> = class
  public
    class function IsEqual (lhs, rhs: T): Boolean;
  end;

class function CompareHelper <T>.IsEqual (lhs, rhs: T): Boolean;
begin
  Result := lhs.Equals (rhs);
end;

Das funktioniert dann auch für skalare Typen, da diese in .NET die nötigen Interfaces unterstützen. (Concept Maps gehen übrigens in eine sehr ähnliche Richtung.)

Da Delphi für Win32 kein "rooted type system" hat, ist das dort nicht so einfach. Gegenwärtig muß man sich mit dem Übergeben eines Comparers etc. behelfen. (Allerdings ist es den Äußerungen der Zuständigen in den CodeGear-Newsgroups zufolge recht wahrscheinlich, daß sich das in den kommenden Versionen noch ändert.)

Shade Of Mine schrieb:

Aber ich kenne die Templates in Delphi nicht - habe nur sehr gemischtes darüber gehört. Kannst du deren funktionalität mal näher erklären?

http://sjrd.developpez.com/delphi/tutoriel/generics/

Shade Of Mine schrieb:

Ist in C++ nur wegen der fehlenden standardisierten ABI nicht möglich.

Wie kommst du denn darauf? Was hat das ABI damit zu tun, daß Templates nicht untypisiert geparst werden können, weil sie nur ein flexibel konfigurierbarer Präprozessormechanismus sind?

Shade Of Mine schrieb:

Deshalb tut man precompiled header verwenden um den kompilierungsaufwand zu reduzieren.

Sagte ich ja bereits. Aber damit ist C++, ohne daß es am Zeilendurchsatz des Compilers läge (s.o.), immer noch deutlich langwieriger zu übersetzen als Sprachen mit einem vernünftigen Modulkonzept, und die Fehlermeldungen sind auch nicht besser.