ich hätte nicht gedacht, dass tatsächlich *alles* das aufgenommen werden kann.

vielleicht noch schnell erwähnen, was denn nun tatsächlich drin ist (und es bis vor kurzem noch nicht war)
benutzerdefinierte literale (yay!)
concepts (ok, das *musste* einfach sein) inkl. riesige mengen an vordefinierten concepts, die neue for-schleife
lambda-ausdrücke (woo-hoo)
die multithreading bibliothek plus - neu: futures

ich hätte nicht gedacht, dass tatsächlich *alles* das aufgenommen werden kann.

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

Muß ich mir wohl doch noch mal den Draft genauer anschauen!

vielleicht noch schnell erwähnen, was denn nun tatsächlich drin ist (und es bis vor kurzem noch nicht war)
benutzerdefinierte literale (yay!)
concepts (ok, das *musste* einfach sein) inkl. riesige mengen an vordefinierten concepts, die neue for-schleife
lambda-ausdrücke (woo-hoo)
die multithreading bibliothek plus - neu: futures

ich hätte nicht gedacht, dass tatsächlich *alles* das aufgenommen werden kann.

Threads finde ich mal richtig geil.

Was sind denn "benutzerdefinierte Literale"? Ich dachte, Literale sind immer benutzerdefiniert.

Edit: Ah ja, ich habs gefunden.

Concepts
Threads sind natürlich auch gut, auch wenn boost die so schon bereitgestellt hat. Vielleicht bietet boost dann bald auf den Standard aufbauend higher-level Threading-Zeug.

Warte einfach auf den TR2.

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.

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.

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

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.

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?

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.

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

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

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.

cout << __cplusplus << endl;

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

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

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

?

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.