spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Und warum? Würde mich wirklich interessieren.

Ps. weak_ptr: In addition," std::weak_ptr is used to break circular references of std::shared_ptr."

Zitat von »H5::«

Und warum? Würde mich wirklich interessieren.

Das hab ich ja hier schon ausführlich erklärt...

Sorry, aber in dem Text finde ich leider keine Aussage zum (shared_ptr +) weak_ptr. Und genau dies interessiert mich.

Du findest dort die Erklärung, wieso man hier keinen shared_ptr verwendet und weak_ptr ist damit automatisch nicht mehr relevant...

Ich verstehe.

Um mal ein wenig zurück zu blicken. Wie hat man es denn früher gemacht?
Man hat sich einen Zeiger in einem Objekt erstellt, und entweder Referenzen oder Kopien des Zeigers nach außen zurück gegeben. Hier konnte man sich genauso wenig gegen deletes schützen, die von außen kommen.
Warum also sollte das mit den unique_ptrs anders laufen?

Um deinen Gedanken mal zu betrachten:
Natürlich kann man einen shared_ptr statt unique nutzen, dadurch wird vieles ein wenig robuster, aber verursacht eben auch mehr Overhead. Der weak_ptr muss bei jeder Referenzierung erst einmal prüfen, ob der Zeiger überhaupt noch gültig ist. In den meisten Fällen schiebt man allerdings keine permanenten Zeiger in der Gegend herum, sondern holt sie sich kurz vorher vom Besitzer (zugegeben, das verursacht auch einen gewissen Overhead, allerdings nur einmalig). Möchte man einen perma Zugriff ermöglichen, empfiehlt es sich meiner Meinung nach eher eine ID oder ein Handle zu nutzen und bei Ungültigkeit eine exception zu werfen. So hat man direkt Feedback, wann es denn nicht mehr funktioniert, statt sich später darüber zu wundern warum es an einer Stelle noch funktioniert und an der anderen nicht. In den aller meisten Fällen ist der Besitzer eben sehr offensichtlich zu ermitteln.

Im Übrigen bin ich auch eher ein Fan von unique_ptr und Referenz nach außen hin vergeben. So spart man sich direkt die nullptr checks.

Robuster wird durch shared_ptr gar nichts. shared_ptr und unique_ptr haben ganz klare und nicht überlappende Anwendungsgebiete; shared_ptr braucht man in der Praxis sehr selten...

Und wenn man meint einen shared_ptr zu brauchen, sollte man eine Zweitmeinung einholen (die vermutlich das Gegenteil besagen wird).

Es wird dadurch robuster, dass man sich über die Existenz des Objekts hinter dem Zeiger keine Gedanken mehr machen muss. Die Frage bleibt bei unique_ptr dann doch immer noch.

Mag sein, dass du das nicht als "robuster" betiteln würdest, aber auf Grund dieses Verhaltens neigen eben viele Leute, die das erste mal mit smartptr hantieren zu den shared_ptrs.

Nein, sie greifen zu shared_ptr, weil sie damit glauben eine Art Reference Counting System nutzen zu können (ähnlich zu Swift oder Rust), was sich ähnlich wie Managed Memory in Java oder C# verhält und man sich keinerlei Gedanken mehr machen muss. Dafür ist shared_ptr aber gar nicht gedacht und zyklische Referenzen sind damit ganz schnell gebaut und dann war's das mit dem Speicher.