[C++11] Visual Studio Next und C++11
-
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 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.
-
_matze schrieb:
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?
-
Jodocus schrieb:
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
-
Dravere schrieb:
@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.
-
_matze schrieb:
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.
-
Mir scheint, bei Microsoft investiert man lieber nach Managed C++ und C++/CLI in nochmal andere, mit beidem inkompatible Spracherweiterungen.
http://msdn.microsoft.com/en-us/library/windows/apps/hh454076.aspx
-
Joah, MinGw hat in letzter Zeit einen richtigen Popularitätsschub bekommen.
Hoffentlich nehmen sich das die MinGW Entwickler zu Herzen und machen das Ding jetzt mal richtig flott.
-
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.
-
Ethon__ schrieb:
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.
-
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?
-
Überseher? schrieb:
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.
-
drakon schrieb:
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..
-
Wozu soll man denn das bisschen Platz sparen? Die Größe als Information ist doch schon praktisch..
-
Sowieso. Die sizeof(size_t) Bytes wären beim dem Verlinkungsoverhead sowieso nicht mehr als ein Tropfen auf dem heißen Stein.
-
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.)
-
SeppJ schrieb:
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.
-
SeppJ schrieb:
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?
