spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn es nicht nötig wäre, bräuchtest du keinen shared_ptr, denn dann wäre die Lebensdauer ja immer korrekt garantiert.

Versteh ich durchaus.
In Deinem Beispiel mit Sprite und Textur wüsste ich aber kein Szenario, wo das Sprite länger existieren sollte als die Textur. Irgendjemand besitzt schließlich das Sprite. Und dieser jemand besitzt entweder auch die Textur oder hat eine Referenz von jemandem, der noch länger lebt.
Also... an welches Szenario genau denkst Du, wo ein Sprite länger leben könnte als eine Textur?

Na nenn mir doch einfach mal ein Beispiel, wo das Sprite länger leben würde als die Textur. Nur so können wir an dem Problem arbeiten und es analysieren. Mir fällt da kein passendes Beispiel ein, denn das Sprite soll ja etwas darstellen und die Textur ist ein Teil dieser Darstellung.

Zitat von »Architekt«

Das beste Beispiel was mir dazu einfällt wären die Klassen Sprite und Texture von SFML, zumindest ab Version 2.0. Dort muss man auch darauf achten, dass die Texture eine mindestens ebenso lange Lebensdauer hat, wie das Sprite.
Bis Version 1.6 wurde das meines Wissens auch durch eine shared_ptr ähnliche Struktur gelöst. Allerdings bedeutet dieses Vorgehen ja, dass wirklich jede übergebene Textur auf den Heap landet, auch wenn dies gar nicht nötig wäre.

Sich genau diese Dinge zu überlegen, ist nunmal, was Softwaredesign eben so ausmacht...

Sehe ich anders. Aber das ist wie dot schon sagt eine Frage des Designs. Aus meiner Sicht braucht ein Sprite eine Textur, sollte diese aber keinesfalls besitzen (=die Lebensdauer der Textur verwalten). Ich sehe das auch gar nicht als notwendig an.
Ich sehe das eher wie "einen Pilz im Wald". Er lebt an den Wurzeln eines Baumes und braucht diesen um zu existieren. Dennoch hat er auf die Lebensdauer des Baums keinen Einfluss. Mehrere Pilze können sogar an einem Baum wachsen und auch von denen hat keiner Einfluss auf das Leben des Baums.