C++0x is feature-complete!

[Bulli]

Das es eine Liste gab, was in TR2 aufgenommen wird, ist mir so nicht bekannt. Es gab lediglich zu den eingereichten Themen hin und wieder einen Vermerk, das es für TR2 vorgemerkt wird. Aber der TR2 wurde ja sowieso erstmal zurück gestellt, weil man sich voll und ganz auf C++0x konzentrieren wollte. Danach geht es dann mit TR2 weiter.

Was aber bisher ein Kandidat für TR2 war: boost.date und boost.filesystem

boost.thread wurde bisher vorgeschlagen, aber immer zurück gewiesen (neuer Anlauf mit Verbesserungen wurde aber immer begrüsst!). boost.asio wurde auch mal vorgeschlagen, aber der TR2-Prozess wurde bekanntlich unterbrochen.

Diese Infos kann man immer ganz gut in der Boost-Mailingliste mitverfolgen.

[queer_boy]

Bulli schrieb:

Das es eine Liste gab, was in TR2 aufgenommen wird, ist mir so nicht bekannt. Es gab lediglich zu den eingereichten Themen hin und wieder einen Vermerk, das es für TR2 vorgemerkt wird. Aber der TR2 wurde ja sowieso erstmal zurück gestellt, weil man sich voll und ganz auf C++0x konzentrieren wollte. Danach geht es dann mit TR2 weiter.

Was aber bisher ein Kandidat für TR2 war: boost.date und boost.filesystem

boost.thread wurde bisher vorgeschlagen, aber immer zurück gewiesen (neuer Anlauf mit Verbesserungen wurde aber immer begrüsst!). boost.asio wurde auch mal vorgeschlagen, aber der TR2-Prozess wurde bekanntlich unterbrochen.

Diese Infos kann man immer ganz gut in der Boost-Mailingliste mitverfolgen.

nein, es gab keine liste von dingen, die definitiv aufgenommen werden sollen; nur welche eben wahrscheinlich drin sein werden.
schade, auch wenn sich die arbeit auf C++0x konzentriert, muss man ja diese info nicht gleich völlig zurückziehen.

[Dravere]

Bulli schrieb:

Lambda-Ausrücke sind drin? Als Sprachfeature oder über Templates?

Falls du es noch nicht gefunden hast oder auch ein anderer sich das fragt. Die sind als Sprachfeature drin, also keine templates wie bei Boost. Wir haben ja sogar einen Artikel im Magazin:
http://magazin.c-plusplus.net/artikel/CPlusPlus09%20(Teil%201)%20-%20Ein%20%DCberblick%3A%20Sprachfeatures

So schön und absolut geil der neue Standard auch wird, so hat es meiner Meinung schon zwei ziemlich negative Punkte.
1. Wird es wohl Ewigkeiten dauern, bis die Compiler den neuen Standard völlig unterstützen.
2. Es fehlen immer noch gewisse wesentliche Punkte. Als Beispiel kann man da wohl eine bessere Datum&Zeit Bibliothek nennen oder eine bessere String Unterstützung. Wie haben nun UTF-8/16/32 Strings, aber können wir die sinnvoll vergleichen?

Naja, aber immerhin geht es voran
Und ich bin schon ganz gespannt, wie es mit den neuen Features sein wird, beim Programmieren. Kann es kaum erwarten ...

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

Grüssli

[frager_]

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

[Bulli]

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?

[Bulli]

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

[Gast]

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.

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