Wie lange hat es gedauert bis ihr alle Aspekte von C++ verinnerlicht hattet?
-
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.
-
Wo es gerade um RValue References geht: Gibt es eigentlich irgendwo ein Quiz, mit dem man sich die einzelnen Aspekte abfragen kann?
-
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!
-
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! :=)
-
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...
-
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.
-
Implementier mal deine Version von unique_ptr, das ist im Prinzip genau das Konzept.
-
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)...
-
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.
-
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...
-
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.
-
Decimad schrieb:
Mag Faulheit sein, [...]
In der Regel ist es das wohl, ja.
shared_ptrsagt 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...
-
Decimad:
Vielleicht ist das mein Problem die ganze Zeit: Für mich ist das dann einfach kein Kopieren mehr, das ist dann Moven.Aber movable semantics heißt doch nicht, dass Kopieren ausgeschlossen ist, meinte dot gerade. Also muss die Besitzübertragung doch nicht automatisch bei Übergabe geschehen, sondern nur, wenn es eben nicht kopierbar ist, also gemoved wird.
Edit:
Aber egal, ich hab das alles, glaube ich, schon verstanden. Mir war eben nur nicht so klar, wo ihr das Ausmaß in RValue-Referenzen seht, sodass ihr es als das Feature schlechthin betrachtet. Gut, Smartpointer profitieren ebenfalls enorm davon. Die Erweiterung der Standardbibliothek finde ich jedoch im Generellen auch schon sehr bewegend.
-
Eisflamme schrieb:
Vielleicht ist das mein Problem die ganze Zeit: Für mich ist das dann einfach kein Kopieren mehr, das ist dann Moven.
Naja, man könnte Moven jetzt als einen Sonderfall von Kopieren betrachten. Die Grundidee hinter move semantics ist, dass man über rvalue references im Prinzip den copy constructor für die Fälle, wo ein move möglich ist, überladen kann...
-
Hm, könnte man, aber für mich ist das genau so wie bei nem Dateiordner, es gibt Verschieben (Move) und es gibt Kopieren (Copy). Bei Verschieben ist nachher vom Ursprung etwas weg, bei Kopieren eben nicht. Da macht es für mich nicht so viel Sinn als Sonderfall von Kopieren zu betrachten. Und heißt ein Move-Constructor immer noch (überladener) Copy-Constructor?
-
Dass einem immer gleich schlechtes Design vorgeworfen werden muss
Wann immer ich shared_ptr verwende, dann aus gutem Grund, und mag es nur wesentlich übersichtlicher Quellcode mit viel weniger offenen Implementierungsdetails beim Clientcode sein (Dass und wie Ressourcen geshared werden, soll den gar nicht interessieren). Wenn das schlechtes Design ist, dann mit gutem Gewissen
Ich bräuchte mal ein Schlechtes-Design-Fähnchen!
-
Eisflamme schrieb:
Edit:
Aber egal, ich hab das alles, glaube ich, schon verstanden. Mir war eben nur nicht so klar, wo ihr das Ausmaß in RValue-Referenzen seht, sodass ihr es als das Feature schlechthin betrachtet. Gut, Smartpointer profitieren ebenfalls enorm davon. Die Erweiterung der Standardbibliothek finde ich jedoch im Generellen auch schon sehr bewegend.Natürlich, aber rvalue references verändern die Sprache an sich fundamental. Die Erweiterungen der Standardbibliothek sind selbstverständlich auch super und profitieren von rvalue references, lambdas etc., aber wären wohl großteils auch einfach so möglich bzw. waren über boost sowieso bereits vor C++11 verfügbar...
Edit: Natürlich ist die Einführung eines memory model und die thread-aware abstract machine etc. in C++11 auch ein sehr wichtiger Schritt. Aber diese Dinge ließen sich davor auch über Libraries beherrschen. Oder nehmen wir z.B. variadic templates; die sind natürlich wahnsinnig praktisch und ich möchte nicht darauf verzichten müssen, aber im Prinzip sind das nur Typelists fix in die Sprache gebastelt, also auch wieder etwas, das vor C++11 (zumindest im Wesentlichen) nicht strikt unmöglich war. Die meisten neuen Features sind eben Komfortfeatures und viele davon (variadic templates, auto, lambdas usw.) sind so praktisch, dass ich sie nicht missen wollte. Aber rvalue references erlauben mir, Dinge auszudrücken, die ich zuvor rein prinzipiell, egal wie hoch auch der Aufwand, nicht ausdrücken konnte...
Z.B. im Umgang mit OpenGL haben sich rvalue references für mich in der Praxis als unbezahlbar herausgestellt.
