[C++11] Visual Studio Next und C++11
-
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?
-
DasIstEinJoke schrieb:
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.
-
Kein Wunder, der große Topic ist WinRT in Windows 8 : http://www.c-plusplus.net/forum/292706
-
Wen interessiert bitte die Größe einer verketteten Liste (egal ob einfach oder doppelt verkettet)?
Ü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)?
-
314159265358979 schrieb:
Ü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.
-
314159265358979 schrieb:
Wen interessiert bitte die Größe einer verketteten Liste (egal ob einfach oder doppelt verkettet)?
Es war DAS Argument für die einfach verkettete Liste. Im Embedded Bereich wollte man nicht den Speicheroverhead einer doppelt verkettete Liste bezahlen, also hat man scih selbst die einfach verkettete Programmiert.
-
Ich rede von der .size() Funktion...
