spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo zusammen,

Ich habe eine Klasse, die ein Cache für Ressourcen darstellt. D.h. wenn der Benutzer eine Ressource anfordert, wird geprüft, ob sie schon mal geladen wurde, und in dem Fall zurückgegeben. Ansonsten wird sie automatisch geladen.

Nun überlege ich mir, wie der Zugriff aussehen soll. Momentan verwende ich ein eigenes Smart-Pointer-Klassentemplate ResourcePtr<T>. Der Vorteil dabei ist, dass ich z.B. tracken kann, wer die Ressource gerade verwendet (für Debugging, oder um Freigabe zu erzwingen). Allerdings überlege ich mir, auf shared_ptr<T> umzusteigen, weil es sich hierbei um einen Standard-Smart-Pointer handelt, den jeder kennt. Ausserdem kann dann die Ressource ohne Abhängigkeit zu meinem Ressourcen-Cache weitergereicht werden. Auf der anderen Seite würde ich etwas Flexibilität verlieren und hätte keine Möglichkeit mehr, später allfällige Features zur Smart-Pointer-Klasse hinzuzufügen.

Der Smart-Pointer würde so oder so Custom-Deleter anbieten, damit man auch normale Objekte reinpacken kann, die nicht vom Cache geladen werden. Damit könnte man sogar Null-Deleter verwenden und z.B. Stack-Objekte referenzieren, ohne dass diese zerstört werden.

Was findet ihr aus Anwendersicht sinnvoller? Spezialisierter ResourcePtr oder allgemeingültiger shared_ptr?

Und kennt ihr Bibliotheken, die die eine oder andere Möglichkeit verwenden? Ich habe bisher vor allem Ogre gefunden, wo ein spezifischer SharedPtr verwendet wird.

Primär SFML-Ressourcen wie Bilder, Schriftarten, Musik, etc. Der Cache ist als Template realisiert, T steht dabei für die entsprechende Ressourcenklasse (daher auch z.B. shared_ptr<T> für die Rückgabe).

Meinst du, es wäre besser, wenn der Ressourcenmanager alle Ressourcen besässe? Dann müsste der Benutzer jeweils sicherstellen können, dass er länger lebt als die Ressourcen. Das wäre auch eine Möglichkeit, momentan können Ressourcen unabhängig von ihrem Erzeuger weiterleben. Sowas wie ein Singleton möchte ich aber nicht erzwingen.

Das "in ein Objekt packen" läuft doch auf eine Art Smart-Pointer hinaus, oder?

Zitat von »dot«

Nicht unbedingt. Ich denke da an Objekte die statt direktem Zugriff auf die Daten ein Interface dafür bieten was du mit den Daten so anstellen willst.

Das geht in meinem Fall nur begrenzt, da viele Klassen Vollzugriff benötigen (z.B. muss ein sf::Sprite auf ein sf::Image verweisen).

Zitat von »dot«

Nicht alle, nur die die er verwaltet. Ist eben die Frage ob es notwendig wird bestimmte Ressourcen zur Laufzeit wieder freizugeben.

Die Möglichkeit zur Freigabe möchte ich schon haben, allerdings tendiere ich dazu, dass nur unbenutzte Ressourcen freigegeben können. Für eine erzwungene Freigabe könnte ich shared_ptr ohnehin nicht nehmen.

Das Problem bei rohen Zeigern ist, dass ich nicht kontrollieren kann, ob eine Ressource noch benutzt wird. Strategien wie "gebe frei sobald unbenutzt" funktionieren also nicht mehr, der Benutzer muss alles explizit befehlen (oder auf den Destruktor warten). Zusätzlich kann es zu Dangling-Pointers kommen, falls aus Versehen zu früh freigegeben wird. Von daher sind Smart-Pointer schon praktisch. Ich denke auch, der Overhead des Reference-Counters und allfälliger Synchronisierungen ist akzeptabel.

Ok, vielen Dank für deine bisherigen Antworten!

Zitat von »dot«

Naja, in so einem Fall wäre Reference-Counting natürlich eine praktikable Lösung.

Was würdest du aus User-Sicht vorziehen, einen std::tr1::shared_ptr oder einen spezifischen Smart-Pointer? Oder spielt das keine Rolle?

Was meinen andere Leute dazu?