[C++11] Visual Studio Next und C++11
-
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...
-
SeppJ schrieb:
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.
Gnarf. Bin ich soo schlimm?
-
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)?
Kann gut sein. Und weißt Du auch, warum es bei splice O(n) ist? Weil splice mitzählen muss, wie viele Elemente eingefügt werden, damit Du schließlich .size() in O(1) anbieten kannst. Entweder oder. Ich habe den alten Standard gerade nicht zu Hand, aber falls dort bei beiden Operationen O(1) stand, war das ein Defekt, da so'was nicht möglich ist.
Bei forward_list kann mit Wegfall von size() das splice() in O(1) angeboten werden.
Einfach mal nachdenken. Ist ja schlimm, wie hier mit Halbwissen eher unbegründet auf vieles rumgehackt wird. Das ging mir im WinRT-Thread auch schon auf den Keks.
-
krümelkacker schrieb:
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)?
Kann gut sein. Und weißt Du auch, warum es bei splice O(n) ist? Weil splice mitzählen muss, wie viele Elemente eingefügt werden, damit Du schließlich .size() in O(1) anbieten kannst. Entweder oder. Ich habe den alten Standard gerade nicht zu Hand, aber falls dort bei beiden Operationen O(1) stand, war das ein Defekt, da so'was nicht möglich ist.
Das fällt anscheinend bei forward_list weg, so dass splice dort in O(1) laufen kann -- auf Kosten einer fehlenden O(1) size-Funktion.
Einfach mal nachdenken. Ist ja schlimm, wie hier mit Halbwissen eher unbegründet auf vieles rumgehackt wird. Das ging mir im WinRT-Thread auch schon auf den Keks.
Und woher schließt du darauf, dass ich das nicht weiß? Ich habe das Zeug sogar schon selbst implementiert, stell dir vor.
-
314159265358979 schrieb:
Ich habe das Zeug sogar schon selbst implementiert, stell dir vor.
314159265358979, unser Elite Hack0r
-
Keine Eier, mit dem richtigen Account zu posten?
