[C++11] Visual Studio Next und C++11

[drakon]

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.

[DasIstEinJoke]

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?

[SeppJ]

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.

[Zeus]

Kein Wunder, der große Topic ist WinRT in Windows 8 : http://www.c-plusplus.net/forum/292706

[314159265358979]

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)?

[camper]

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.

[otze]

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.

[314159265358979]

Ich rede von der .size() Funktion...

[pumuckl]

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?

[krümelkacker]

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.

[314159265358979]

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.

[_ololol_]

314159265358979 schrieb:

Ich habe das Zeug sogar schon selbst implementiert, stell dir vor.

314159265358979, unser Elite Hack0r

[314159265358979]

Keine Eier, mit dem richtigen Account zu posten?

[lolol]

Weil man ja so viel Eier braucht um im Internet unter einem Nick wie 314159265358979 zu posten, ne?

[314159265358979]

Und worin liegt deiner Meinung nach der Unterschied zwischen meinem Nick und einem x-beliebigen, anderem registriertem?

Warum postest du nicht einfach mit deinem richtigen Account? Angst deinen Ruf zu ruinieren? Ich kann meinen Ruf nicht mehr ruinieren, bei mir ist das schon zu spät.

[Bashar]

314159265358979 schrieb:

Warum postest du nicht einfach mit deinem richtigen Account?

Ist doch egal, unregistrierte Postings (zumal mit solch debilen Nicks) sind eh zu 99% schwachsinnig. Das ist für mich mittlerweile wie die Hundescheiße auf der Straße. Wär mir lieber, wenn es das gar nicht gäbe oder wenn es öfter mal einer wegmacht, aber mittlerweile regt es mich kaum noch auf, einfach beiseite lassen. Hauptsache nicht reintreten.

BTW kann es sein, dass du dir etwas viel einbildest, wenn du glaubst, dass sich jemand extra für dich ausloggt.

[314159265358979]

Dafür muss man sich nicht ausloggen, ein zweiter Browser reicht schon...

[rüdiger]

Ignoriert doch einfach die Trolle . Dann kann ein Mod ggf. einfach das Trollposting löschen und muss nicht die ganze Diskussion filtern.

Die SGI STL und die libstdc++ implementieren std::list übrigens mit size() O(n) http://gcc.gnu.org/onlinedocs/libstdc++/manual/containers.html#containers.sequences.list

[314159265358979]

Meine Implementierung hat auch O(n) size.

[krümelkacker]

314159265358979 schrieb:

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

Und woher schließt du darauf, dass ich das nicht weiß? [...]

Das klang so überrascht. Hab' ich wohl falsch interpretiert.