[...]
-
[...]
-
Die Klassen A, B und C sollten wissen, wie man eine deep copy von sich macht. Dann rufst du nur noch auf a_ptr->copy(); (Wobei ich es auch komisches Design finde so viele shared_ptr insbesondere auf mutable Daten in einem Programm zu haben.)
-
cooky451 schrieb:
(Wobei ich es auch komisches Design finde so viele shared_ptr insbesondere auf mutable Daten in einem Programm zu haben.)
Wenn jemand so eine Frage stellt, dann ist shared_ptr zu 95% der falsche Weg.
-
[...]
-
Elementus schrieb:
Wieso bzw. wie sollte es denn besser gehen?
Welchen Grund hast du, shared_ptr zu benutzen? (Dazu gehoert: Welchen Grund hast du einen Pointer zu benutzen? + Welchen Grund hast du fuer shared ownership?)
-
[...]
-
Elementus schrieb:
Hm, ich erzeuge dynamisch Objekte in meinem Programm, baue daraus eine Datenstruktur und brauche dadurch mehrere Pointer, die auf das gleiche Objekt zeigen.
Du sagst uns nur, was du machst, damit kann man alles begründen. Bitte mehr Hintergrundinformationen.
-
Elementus schrieb:
Hm, ich erzeuge dynamisch Objekte in meinem Programm, baue daraus eine Datenstruktur und brauche dadurch mehrere Pointer, die auf das gleiche Objekt zeigen.
Das mag die Zeiger erklären, ist aber noch kein hinreichender Grund für
shared_ptr.
-
[...]
-
Elementus schrieb:
Ein unique_ptr geht auch nicht, weil ich dann die Pointer nicht Methoden übergeben kann bzw. dann müsste ich sie in einen shared_ptr umwandeln.
lol? Du übergibst eine Referenz.
Bei der Datenstruktur geht es um einen Baum, dazu habe ich einige Beispiele gefunden die std::shared_ptr benutzen um einen Knoten zu implementieren. Die beiden Kinder sind dann bei binären Bäumen zwei std::shared_ptr auf die Kindsknoten oder nen vector von std::shared_ptr auf viele Kinder. Elternknoten ist dann ein std::weak_ptr. Es gibt auch die andere Meinung, dass Smartpointer bei Bäumen overkill sein, so habe ich es zumindestens bei Stackoverflow gelesen.
Wenn du einen Pointer auf den Elternknoten hast, macht shared_ptr keinen Sinn. Siehe https://www.c-plusplus.net/forum/p2435825#2435825.
Wie gesagt, wenn du keinen Grund für shared_ptr hast, dann nimm unique_ptr.Wenn man vor die Knoten jetzt noch eine Baumklasse packt, die den Wurzelknoten beinhaltet, dann gibts dort auch noch einen std::shared_ptr für. Und wenn man davor noch eine Klasse schaltet, wo mehrere Bäume im Spiel sind, dann hat man nochmal einen vector von std::shared_ptr.
Auch hier kein Grund für shared_ptr.
Und jetzt würde ich gerne von einem Baum eine komplette Kopie haben.
Dann schreib dir halt einen Kopierkonstruktor. shared_ptr ist hier nur behinderlich.
Ich hoffe mal, dass das jetzt ein hinreichender Grund ist oder liege ich daneben.
Nein. Es gibt gründe für Bäume mit shared_ptr, aber die hast du nicht genannt.
-
Elementus schrieb:
Ein unique_ptr geht auch nicht, weil ich dann die Pointer nicht Methoden übergeben kann bzw. dann müsste ich sie in einen shared_ptr umwandeln.
Das 'shared' in
shared_ptrbezieht sich auf den Besitz, nicht auf den 'Pointer'.
-
[...]