C++0x is feature-complete!

[.filmor]

Hmm? Also eigentlich nicht. __cplusplus ist normalerweise einfach irgendwas != 0. Haben die das für C++0x geändert?

[queer_boy]

es sollte zumindest bei standardkonformen compilern 199711 sein, in C++0x dann eben 200912 oder so)

das problem ist wohl, dass kein compiler wirklich standardkonform ist (export), was aber schade ist, da so sogar das makro unnütz ist.
hm...

[*rant*]

queer_boy schrieb:

das problem ist wohl, dass kein compiler wirklich standardkonform ist (export), was aber schade ist, da so sogar das makro unnütz ist.

Was ist eigentlich aus diesem export geworden? Ist es weiterhin fester Bestandteil des neuen Standards oder wurde es als obsolete markiert? Letzteres würde mich freuen, da wir bisher bekanntlich auch gut ohne export ausgekommen sind. Nun vernünftig umsetzbare Features sollten entfernt werden, da sie die weitere Entwicklung des Standards behindern

[audacia]

/rant/ schrieb:

Was ist eigentlich aus diesem export geworden? Ist es weiterhin fester Bestandteil des neuen Standards oder wurde es als obsolete markiert? Letzteres würde mich freuen, da wir bisher bekanntlich auch gut ohne export ausgekommen sind.

AFAIK wird am Status von export nichts geändert. Außerdem ist es so ganz unnütz meiner Ansicht nach nicht; spätestens, wenn man zu Modulen als Ablösung des bisherigen Header-Konzeptes kommt, dürfte wieder darüber geredet werden.

Implementierbar ist es übrigens auch. Die Generics in Delphi 2009 sind im Prinzip sowie in technischer Hinsicht die Delphi-Variante von export templates.

/rant/ schrieb:

Nun vernünftig umsetzbare Features sollten entfernt werden, da sie die weitere Entwicklung des Standards behindern

?

[Nexus]

audacia schrieb:

Implementierbar ist es übrigens auch.

Aber nicht so wie vom Standard vorgesehen. Meines Wissens gibt es nur sehr wenige Compiler, die dieses Feature unterstützen (Comeau). Und selbst dort ist es nicht gerade sauber gelöst, sodass man oft sogar noch längere Kompilierzeiten mit export in Kauf nimmt.

[Simon2]

Nexus schrieb:

audacia schrieb:

Implementierbar ist es übrigens auch.

Aber nicht so wie vom Standard vorgesehen. Meines Wissens gibt es nur sehr wenige Compiler, die dieses Feature unterstützen (Comeau). Und selbst dort ist es nicht gerade sauber gelöst, sodass man oft sogar noch längere Kompilierzeiten mit export in Kauf nimmt.

Ich habe mal mit dem "templateregistry"-Feature des IBM xlC herumgespielt ... aber das Ergebnis ließ übel zu wünschen übrig. Einerseits habe ich es nicht hinbekommen, Fremdlibs sauber zu linken (da hätte ich vermutlich noch einen Layer zwischen ziehen müssen - was kein Vergnügen gewesen wäre).
Andererseits explodierte die Compilezeit. OK - prinzipiell habe ich da keine so groen Anforderungen, weil ich viel im Hintergrund baue. Aber wenn das Feature einen Komplettbuild von 40 Minuten auf über 12 Stunden hochschraubt, muss es schon sehr überzeugende Vorteile mitbringen.

Gruß,

Simon2.

[audacia]

Simon2 schrieb:

Ich habe mal mit dem "templateregistry"-Feature des IBM xlC herumgespielt ... aber das Ergebnis ließ übel zu wünschen übrig. Einerseits habe ich es nicht hinbekommen, Fremdlibs sauber zu linken (da hätte ich vermutlich noch einen Layer zwischen ziehen müssen - was kein Vergnügen gewesen wäre).
Andererseits explodierte die Compilezeit. OK - prinzipiell habe ich da keine so groen Anforderungen, weil ich viel im Hintergrund baue. Aber wenn das Feature einen Komplettbuild von 40 Minuten auf über 12 Stunden hochschraubt, muss es schon sehr überzeugende Vorteile mitbringen.

Du meinst das hier?
Vielleicht verstehe ich den Text nicht richtig, aber wenn dieses Feature tatsächlich nur verhindert, daß Template-Instantiierungen mit demselben Typen mehrfach generiert werden, dann sehe ich weder den Vorteil (höchstens, daß die Übersetzungszeit verringert würde - aber das scheint ja nun nicht eben der Fall zu sein) noch den Zusammenhang mit export templates - die hatte ich technisch eher in der Nähe von vorcompilierten Headern vermutet.

[Bulli]

audacia schrieb:

den Zusammenhang mit export templates - die hatte ich technisch eher in der Nähe von vorcompilierten Headern vermutet.

Wohl eher mit Template-Implementierung in der CPP-Datei (bzw. allgemein in der Übersetzungseinheit).

Vorkompilierte Header sind PCH, haben aber mit ISO-C++ nichts zu tun.

[audacia]

Bulli schrieb:

audacia schrieb:

den Zusammenhang mit export templates - die hatte ich technisch eher in der Nähe von vorcompilierten Headern vermutet.

Wohl eher mit Template-Implementierung in der CPP-Datei (bzw. allgemein in der Übersetzungseinheit).

Was export templates theoretisch sind, weiß ich schon
Nur wird es die Flexibilität von C++ sehr erschweren, für untypisierte Templates bereits Zwischencode zu erzeugen. Eine realistischere Umsetzung wäre daher vermutlich technisch so etwas wie das, was bei PCHs passiert.

Bulli schrieb:

Vorkompilierte Header sind PCH

Ach nein

Bulli schrieb:

..., haben aber mit ISO-C++ nichts zu tun.

Deshalb schrieb ich auch "technisch".

[Simon2]

audacia schrieb:

...Du meinst das hier?
...

Ja.
In meinen Augen (auch ich behaupte nicht, das Feature bis ins Letzte verstanden zu haben) ist das "Versuch, export zu emulieren". Es werden halt nicht nur Mehrfachinstantiierungen verhindert, sondern auch zur Compilezeit des 2.-n. "Nutzers" garantiert dieselbe Implementierung verwendet wie beim ersten Compile - bzw. es fällt auf wenn sich sich die Iplementierung zwischenzeitlich geändert hat.

Ganz konkret hat der xlC-Compiler den Bug (der allerdings von IBM anscheinend nicht behoben werden soll), dass er überall "duplicate symbol"-Warnings rausschmeisst, wo templates verwendet werden. Auch bei std::string, std::vector, ....
Das macht die Suche nach echte "duplicate symbols" (die ich ziemlich ernst nehme) sehr mühsam macht.

Gruß,

Simon2.