C++0x is feature-complete!

Dravere

queer_boy schrieb:

... aber ich glaube mich zu erinnern, dass packaged_task wieder aus dem draft entfernt werden soll.

Ne, ist im letzten Draft noch drin ...

Danke für die Erklärungen, dann ist es wirklich das, was ich gedacht hatte. Grundsätzlich ist es einfach eine extreme Vereinfachung von parallelen Berechnungen? Die Threads warten einfach bei einem get darauf, bis ein anderer Thread den Wert des Futures setzt?
Wäre definitiv äusserst praktisch. Ich habe derzeit selber solche Dinge bereits implementiert, aber bei mir sieht das ausgeprochen komplex aus und ist immer noch sehr unhantlich
Dann freue ich mich um ein Feature mehr auf den neuen Standard

Grüssli

rüdiger schrieb:

frager_ schrieb:

wänn kann ich mit einem ersten experimentalen compiler für diesen draft rechnen? würde sehr gerne mit den neuen features spielen

Der GCC ist da wohl am weitesten http://gcc.gnu.org/projects/cxx0x.html. Concepts und Lambdas sind aber noch eigene Branches.

@Optimizer
Boost.Threads wurde in 1.36 schon ein wenig an C++0x angepasst. Aber da wird sicher in den nächsten Jahren in Boost generell einiges kommen. Interessant wäre vor allem die Frage, wie die bei Boost den Übergang regeln wollen. Wird es ein Boost2 geben, welches speziell für C++0x ist (also unnötigen Libs raus und Libs speziell für C++0x rein) und ein Boost1, welches sich eher an C++98/03 richtet, aber optional auch C++0x-Features nutzt?

Ja, wahrscheinlich wird das demnächst heiß diskutiert. Ich vermute, sie werden die "alten" Compiler nicht so schnell fallen lassen. Angenommen es gibt higher-level Threadzeug, dann wird es für die alten Compiler vielleicht auf boost.thread basieren und für die neuen auf std.thread. Nur wenn man dann die Möglichkeit haben soll, das thread-Objekt zu getten wird es haarig. Letzteres wird dann vielleicht bewusst erstmal ausgespart, ansonsten kann man ja die gleiche Schnittstelle bereitstellen.

So Sachen wie thread selber oder bind könnte dann auch so aussehen:

#ifdef MSVC_10
#include <bind>
#else
...
#endif

Aber stimmt schon, ich bin auch gespannt wie sie es machen werden.

queer_boy

es gibt übrigens ein standard-makro für die version des standards:

cout << __cplusplus << endl;

.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.

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.