Schönes Marketing-Blabla -> "Wir stehen voll hinter C++11 und sehen eine C++ Renaissance."
Und bringen damit 3 neue Features der Sprache heraus

Bis MSVC standardkonform mit C++11 ist, dürfte es wohl bis 2020 gehen mit dem Tempo

Variadic Templates sind übrigens nicht dabei ... und sowieso nichts interessantes ...

Grüssli

New headers: <atomic>, <chrono>, <condition_variable>, <future>, <mutex>, <ratio>, <scoped_allocator>, and <thread>. (And I've removed the broken <initializer_list> header that I accidentally left in VC10.)

Hoffentlich beheben sie auch den Bug in std::function.

Schönes Marketing-Blabla -> "Wir stehen voll hinter C++11 und sehen eine C++ Renaissance."

Leuten wie Herb Sutter glaube ich das sogar

Since January 2007 (when I moved from Outlook Search to VC Libraries), I've been the only MS dev working on the STL.

Die Comments sind teilweise recht lustig. Die scheinen bei MS ja richtig Manpower zu investieren:

Since January 2007 (when I moved from Outlook Search to VC Libraries), I've been the only MS dev working on the STL.

Stephan T. Lavavej

Troll oder Zufall?

Immerhin ein Schritt in die richtige Richtung. Schön ist z.B.:
New headers: <atomic>, <chrono>, <condition_variable>, <future>, <mutex>, <ratio>, <scoped_allocator>, and <thread>. (And I've removed the broken <initializer_list> header that I accidentally left in VC10.)

Erhält man bereits alles grundsätzlich über Boost.
Daher reissen mich die neuen Libraries nicht vom Hocker. Entscheidend sind die Sprachfeatures. Und da sieht es im Vergleich zu anderen Kompilerherstellern lachhaft aus.
Nicht zu vergessen: Wenn VS Next 2012 rauskommt, geht es sicherlich wieder 2-3 Jahre bis zum nächsten Release. Aber wenn dann 2015 die übernächste Version kommt, wird die sicher nicht C++11 standardkonform sein. Daher eben meine Vermutung mit 2020. GCC oder Clang wird wahrscheinlich schon in ein paar Jahren mehrheitlich C++11 standardkonform sein.

pumuckl schrieb:

Dravere schrieb:

Schönes Marketing-Blabla -> "Wir stehen voll hinter C++11 und sehen eine C++ Renaissance."

Leuten wie Herb Sutter glaube ich das sogar

Die Frage ist, was dabei die Wünsche und Vorstellungen von Herb Sutter sind und welche von Microsoft? Microsoft steht hinter Herb Sutter, sobald es allerdings ums Zahlen geht, knickt der Konzern ein?

@camper,
http://social.msdn.microsoft.com/profile/stephan%20t.%20lavavej%20-%20msft/
Scheint ein offizieller Microsoft Mitarbeiter zu sein. Glaube kaum, dass sich so jemand sowas leisten könnte, rumtrollt und Unwahrheiten verzapft.

Grüssli

@camper,
http://social.msdn.microsoft.com/profile/stephan%20t.%20lavavej%20-%20msft/
Scheint ein offizieller Microsoft Mitarbeiter zu sein. Glaube kaum, dass sich so jemand sowas leisten könnte, rumtrollt und Unwahrheiten verzapft.

Verführt trotzdem zum Schmunzeln.

Die Comments sind teilweise recht lustig. Die scheinen bei MS ja richtig Manpower zu investieren:

Since January 2007 (when I moved from Outlook Search to VC Libraries), I've been the only MS dev working on the STL.

Naja, du hast den Teil vergessen:

I work with Dinkumware, headed by P.J. Plauger - the original author of the C++ Standard Library implementation that MS has licensed.

Sie haben halt eine Standard Library lizensiert und arbeiten mit Dinkumware zusammen.

Dravere schrieb:

GCC oder Clang wird wahrscheinlich schon in ein paar Jahren mehrheitlich C++11 standardkonform sein.

Der GCC ist ja jetzt schon ziemlich weit: http://gcc.gnu.org/projects/cxx0x.html Also ist VC11 sehr enttäuschend, was den C++-Support angeht. Das ganze klingt sehr nach VC6-Teil2.

Was ich auch witzig find: Nach der Größenauflistung der Container soll eine std::forward_list mit VC11 nur noch 4 Bytes auf x86 Plattformen groß sein... das bedeutet doch fast sicher dass forward_list::size eine Komplexität von O(n) hat? Das wäre ja ein massiver Fail.

Tja, lies zuerst mal den Standard:

A forward_list satisfies all of the requirements of a container (Table 96), except that the size() member function is not provided.

Falls du dich nun fragst: "Häää??"
Ja ...

Grüssli

Klingt gruselig, seltsame Entscheidung, das so zu implementieren.

Hätten sie nicht einfach bei jedem push_front() den size_value erhöhen können? Dann würde ja size() O(1) sein.

Oder übersehe ich da bloß was?

Ethon__ schrieb:

Klingt gruselig, seltsame Entscheidung, das so zu implementieren.

Hätten sie nicht einfach bei jedem push_front() den size_value erhöhen können? Dann würde ja size() O(1) sein.

Oder übersehe ich da bloß was?

Dann wären es aber nicht mehr lediglich 4 Bytes.

Oder übersehe ich da bloß was?

Dann wären es aber nicht mehr lediglich 4 Bytes.

Die Größeninformation könnte ja auch auf dem Heap liegen

Das ändert am Speicherverbrauch ja nichts..

Eben, das meine ich doch. (Aber jetzt ist die Pointe hin . War wohl nicht so gut, der Scherz.)

drakon schrieb:

Das ändert am Speicherverbrauch ja nichts..

Eben, das meine ich doch. (Aber jetzt ist die Pointe hin . War wohl nicht so gut, der Scherz.)

Hab schon gemerkt, dass du es nicht ernst meinst, aber wirklich witzig finde ich das überhaupt nicht.

drakon schrieb:

Das ändert am Speicherverbrauch ja nichts..

Eben, das meine ich doch. (Aber jetzt ist die Pointe hin . War wohl nicht so gut, der Scherz.)

Wir haben auch einen in der Arbeit, der solche Programmierwitze erzählt, die keiner lustig findet. Bist du's Franzl?

Wir haben auch einen in der Arbeit, der solche Programmierwitze erzählt, die keiner lustig findet. Bist du's Franzl?

Nein, aber nicht jeder Witz kann ein Renner sein. Ich muss das A+-Material für solche Fragen aufsparen bei denen pumuckl den Thread einfach nur mit einem Verweis auf seine Signatur schließen würde.

Überhaupt: Sehe ich das richtig, dass der Standard bei std::list nun eine Implementierung vorsieht, bei der .size() O(1) und der eine Overload von .splice() O(n)?

Überhaupt: Sehe ich das richtig, dass der Standard bei std::list nun eine Implementierung vorsieht, bei der .size() O(1) und der eine Overload von .splice() O(n)?

Das war schon immer die bevorzugte Variante. Immerhin ist das der Grund, warum auch immer die Container mit angegeben werden müssen, und in C++11 sogar const_iterator ausreicht.