C++0x is feature-complete!

Die ersten C++0x-Features sind ja bereits in den gängigen Compilern verfügbar. Z.B. kann der MSVC2005 (8.0) schon die doppelten spitzen Klammern bei Templates:

vector<vector<int>> vec;

Die MSVC9.0-Developer Preview kann schon das auto-Schlüsselwort:

for(auto i = vec.begin(); i != vec.end(); i++)

Es wird sicherlich nicht alles auf einmal umgesetzt werden, aber die Compiler-Hersteller haben dieses Mal bei der Standardisierung viel mehr mitgeredet. Außerdem wurden schon viele Features vorher ausprobiert, wie die Concepts (kann jeder mit dem ConceptsGCC ausprobieren). Selbst Codegears aktueller C++-Compile unterstützt schon C++0x-Features, obwohl gerade dieser Compiler sehr lange nicht standardkonform war.

Ich schätze mal 2013 werden die gängigen Compiler das meiste abdecken.

rüdiger

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?

Sorry, meinte die MSVC10.0-Preview, nicht 9.0!

audacia

Dravere schrieb:

Könnte mir im übrigen jemand einen guten Artikel zu den Futures zeigen? So ganz habe ich die noch nicht begriffen.

Zu denen in C++ nicht, aber eine Erläuterung eines vergleichbaren Features in Delphi Prism:

marc hoffman schrieb:

For example, just recently introduced in Oxygene, there are "future" types, "async" blocks and expressions and "parallel" loops; these make it really easy to write applications that scale out to systems with many CPUs or cores. This is something that will get tremendously important in the near future, as CPU speeds no longer increase, but instead systems get more (and sometimes slower) CPUs. Microsoft is adding infrastructure to leverage this in .NET 4.0, called the "Parallel Framework", or "PFX". The PFX is really just a bunch of classes and functions you can call, but for Prism we went the extra mile to integrate these concepts into the language. So for example, you can now declare a variable to be of a "future" type - which means it will behave very much like a normal variable of a given type, except for one thing: it’s value will be calculated at some point in the future, possibly on a different thread.

So you can write, for instance:
method BinaryTreeNode.Sum: Int32;
begin
   var leftSum: future Int32 := async Left.Sum();
   var rightSum: Int32 := Right.Sum();
   result := Value+leftSum+rightSum;
end;
What we’re doing here is calculating the sum of a binary tree, by basically calculating the left and right side, and then adding everything together. But rather then first calculating Left and waiting for that to return, we do that asynchronously. As a result, leftSum is not a plain Int32, but a future Int32 - meaning a variable that, at some point in the future, will contain the result of our calculation. The hope is that - given enough CPU cores - this value will be calculated by some other thread, while we’re busy calculating rightSum.

The important part is the last statement. As you can see, we’re using leftSum as part of a longer expression here. The takeaway point is that, even though it’s a future, you can work with leftSum as if it were a plain integer. You can do math on it, you could call it’s member methods, etc. The compiler and the runtime will of course take care that at the time you need the value of leftSum, it will be calculated.

In C++ wird das natürlich kein Sprach-, sondern ein Library-Feature. Spezifikationsdetails findest du hier.

queer_boy

die genauen regeln kenne ich auch nicht, aber als beispiel wird es wohl ca. so aussehen, dass du ein "versprechen" (std::promise) machst, ein bestimmtes ergebnis zu liefern (dargestellt durch std::future). sobald die berechnung komplett ist, kannst du über dein std::unique_future auf das ergebnis zugreifen, und zwar thread-safe.

#include <future>
using namespace std;

int main ()
{
   promise<int> pi;
   unique_future<int> fu = pi.get_future();

   pi.set_value (42); //happens-before
   int value = fu.get();
}

das ist natürlich ein sinnfreies beispiel, aber es ist nicht schwer, das promise in einen (mehrere) threads zur bearbeitung zu übergeben bzw. in mehreren threads über std::shared_future darauf zuzugreifen.
interessant wird es erst wie folgt:

#include <thread>
#include <future>
using namespace std;

int main ()
{
   promise<int> pi;
   unique_future<int> fu = pi.get_future();

   thread data { [&] () (pi.set_value(do_sth_dumb())) };
   thread output { [&] () (cout << fu.get() << endl) };

   output.join();
}

bin mir wie gesagt über die verwendung davon noch nicht ganz sicher, aber wenn es tatsächlich so funktionieren sollte, dann werden multithreading programme in C++ sehr leicht zu verwenden sein.

PS. das template std::packaged_task übernimmt die funktion, die ich hier mit einzelnen std::threads nachgebildet habe (also starten eines funktionsobjekts in einem neuen thread, dessen rückgabewert als wert eines promise gesetzt wird + liefern eines passenden futures) - aber ich glaube mich zu erinnern, dass packaged_task wieder aus dem draft entfernt werden soll.

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.