Wie lange hat es gedauert bis ihr alle Aspekte von C++ verinnerlicht hattet?

Kellerautomat

@Eisflamme: Ich finde diese Serie von Artikeln fuer den Einstieg ziemlich gut: http://thbecker.net/articles/rvalue_references/section_01.html

Sone

314159265358979__ schrieb:

Eisflamme schrieb:

Ich denke, ich schließe mich Pi an.

Wie bitte? Ich hab hier doch bisher nicht mal gepostet.
Aber offenbar gehe ich euch schon so sehr ab, dass ihr mich überall seht.

Ok, jetzt kriege ich wirklich einen Anfall.
Bist du gebannt? Ich hab dich durchs halbe Internet getrackt!

Sone schrieb:

314159265358979__ schrieb:

Eisflamme schrieb:

Ich denke, ich schließe mich Pi an.

Wie bitte? Ich hab hier doch bisher nicht mal gepostet.
Aber offenbar gehe ich euch schon so sehr ab, dass ihr mich überall seht.

Ok, jetzt kriege ich wirklich einen Anfall.
Bist du gebannt? Ich hab dich durchs halbe Internet getrackt!

Ich glaube, dass Kellerautomat PI ist.

dot

Eisflamme schrieb:

Auch auf die Gefahr hin jetzt gleich wieder einen dummen Spruch gedrückt zu kriegen, hat jemand kurz einen Link zu den Auswirkungen der RValue-Referenzen? Ich verstehe das Grundprinzip und dass dadurch die Performance deutlich steigen müsste. Geht es schon darum oder was ist euer Kernpunkt?

Abgesehen von dem von Kellerautomat verlinkten Artikel, ist auch dieser hier noch sehr empfehlenswert: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/

Performancepotential ist imo nur ein Nebeneffekt von rvalue references. Der wichtigste Aspekt ist, dass du damit, wie cooky451 schon angedeutet hat, Dinge ausdrücken kannst (move Semantik), die du zuvor einfach nicht richtig ausdrücken konntest. std::auto_ptr ist das beste Beispiel für den gescheiterten Versuch, ownership transfer ohne C++11 zu implementieren...

cooky451

Sone schrieb:

Bist du gebannt? Ich hab dich durchs halbe Internet getrackt!

Na besonders weit scheinst du ja nicht gekommen zu sein.

Sone

Ich glaube, dass schrieb:

Sone schrieb:

314159265358979__ schrieb:

Eisflamme schrieb:

Ich denke, ich schließe mich Pi an.

Wie bitte? Ich hab hier doch bisher nicht mal gepostet.
Aber offenbar gehe ich euch schon so sehr ab, dass ihr mich überall seht.

Ok, jetzt kriege ich wirklich einen Anfall.
Bist du gebannt? Ich hab dich durchs halbe Internet getrackt!

Ich glaube, dass Kellerautomat PI ist.

Näh, Kellerautomat ist nicht so unnötig.

cooky451 schrieb:

Sone schrieb:

Bist du gebannt? Ich hab dich durchs halbe Internet getrackt!

Na besonders weit scheinst du ja nicht gekommen zu sein.

Nein, da haste Recht, ich hab nur folgende Sites gefunden:

http://www.sploder.com/games/members/314159265358979/
http://forum.die-staemme.de/showthread.php?168898-314159265358979
http://www.spieleprogrammierer.de/user/5061-paprikachu/
http://www.herocraftonline.com/main/threads/paprikachu.11143/

Und eine auf tumblr, aber die ist gerade irgendwie off.

Sone

Wo es gerade um RValue References geht: Gibt es eigentlich irgendwo ein Quiz, mit dem man sich die einzelnen Aspekte abfragen kann?

Eisflamme

Okay, Ownership-Transfer gefällt mir, da versteh ich, wieso sich ein Fass öffnet.

Ich denke nur gerade drüber nach, wieso das jetzt für Handles im Speziellen toll ist. Wenn die auf irgendetwas zeigen, kann man es kopieren, das ist schön. Aber wann käme ich denn auf die Idee ein Handle zu moven? Oder geht es nicht darum, sondern um das Objekt dahinter, was gemoved wird? Aber wieso ist das hilfreich?

Jedoch: ich lese diese Artikel, sobald ich dazu komme, vermutlich wird mir das dann eh klar. Danke!

dot

Eisflamme schrieb:

Aber wann käme ich denn auf die Idee ein Handle zu moven?

Was passiert, wenn du ein Handle kopierst? Du hast auf einmal zwei Objekte, mit dem selben Handle...wer von den beiden gibt das Objekt nun wann genau frei?

Der letzte schaltet immer das Licht aus! Oder es gibt Ärger! :=)

dot

Decimad schrieb:

Natürlich das letzte! :=)

Nunja, ein Weg, um das zu erreichen, wäre reference counting. Reference counting ist allerdings mit signifikantem Overhead verbunden und der Fall, dass man tatsächlich shared ownership hat, ist, zumindest meiner Erfahrung nach, extrem selten. Normalerweise gibt es immer nur einen Besitzer und rvalue references erlauben es, genau dieses Konzept korrekt abzubilden...

Eisflamme

Okay, also haben die Handles in dem Fall shared ownership, aber wie löst man das mit RValue-Referenzen? Wenn ich eine Kopie erstelle, habe ich doch dasselbe Problem. Oder erlaubt man keine Kopien, dafür aber Moves? Aber cooky meinte ja, man müsse Kopien nicht verbieten.

cooky451

Implementier mal deine Version von unique_ptr, das ist im Prinzip genau das Konzept.

dot

Eisflamme schrieb:

Okay, also haben die Handles in dem Fall shared ownership, aber wie löst man das mit RValue-Referenzen? Wenn ich eine Kopie erstelle, habe ich doch dasselbe Problem. Oder erlaubt man keine Kopien, dafür aber Moves? Aber cooky meinte ja, man müsse Kopien nicht verbieten.

Man muss das Kopieren nicht verbieten. Ein Typ, der copyable und moveable ist, ist wohl in der Regel der klassische Fall, wo move Semantik als Performanceoptimierung eingesetzt wird (move aus temporärem Objekt). Interessant wird es eben, wenn ein Typ moveable aber nicht copyable ist. C++11 erlaubt es einem damit, explizit auszudrücken und auch statisch zu forcieren, dass eine Ressource zu jedem Zeitpunkt immer nur einen Besitzer haben kann (ich kann explizit aus einem Objekt in ein andere moven, aber nicht ein Objekt in ein anderes kopieren)...

Eisflamme

Okay, jedoch verstehe ich immer noch nicht, wieso das Kopieren dann (für Handle oder unique_ptr) erlaubt sein soll. Das Handle wird ja anscheinend nicht in mehreren Objekten gleichzeitig gehalten, also ist das Kopieren doch untersagt? Und unique_ptr ist doch auch nicht copyable?

Also ich habe shared-Referenzen auf teure Ressourcen, die von vielen Komponenten verwendet werden, die sich aber nicht eigenständig um das ganze geshare kümmern sollen. Mag Faulheit sein, funktioniert aber ganz gut, und sooooo groß ist der overhead jetzt ja nun auch nicht.

dot

Eisflamme schrieb:

Okay, jedoch verstehe ich immer noch nicht, wieso das Kopieren dann (für Handle oder unique_ptr) erlaubt sein soll. Das Handle wird ja anscheinend nicht in mehreren Objekten gleichzeitig gehalten, also ist das Kopieren doch untersagt? Und unique_ptr ist doch auch nicht copyable?

Natürlich, ein std::unique_ptr bzw. allgemein ein Handle ist in der Regel das Paradebeispiel für einen Typen, der moveable aber eben nicht copyable ist...

Eisflamme

Okay, dann habe ich das die ganze Zeit einfach nur sprachlich falsch verstanden. Non-copyableness für Handles und unique_ptr machen ja absolut Sinn. Wobei ich z.B. Handles habe, die kopierbar sind, aber ihren Schöpfer (einen Pool) kennen, der ihnen bei Bedarf verrät, ob die noch gültig sind. Aber gut.

@Eisflamme: Movable semantics bedeuten beim Kopieren immer einen Übergang der Lebenszeitverwaltung zum Zielobjekt. Man kann also von Besitzumstransfer sprechen. Zum Beispiel könnte eine Lib-Funktion ein Objekt erzeugen und dem Aufrufer per unique_ptr returnieren, damit wird schon in der Deklaration vermittel (und später durch die Compilerfehler), dass es sich hier um Besitztumstransfer zum Aufrufer handelt.

dot

Decimad schrieb:

Mag Faulheit sein, [...]

In der Regel ist es das wohl, ja. shared_ptr sagt wohl meistens: "Ich hab keine Ahnung von den Abhängigkeiten und Besitzverhältnissen in meinem Programm und will mir auch keine Gedanken darüber machen". Ist, zumindest meiner Erfahrung nach, natürlich nicht gerade ein Symptom von gutem Design...