denkproblem: Klasse welche von einer anderen klasse verwaltet wird soll zugleich durch einen smartpointer verwaltet werd

[otze]

hört sich ja im ersten augenblick nach nem dicken designfehler an-vielleicht ist es das auch, aber erstmal zum problem:

ich habe eine klasse, welche eine einzelne textur beinhaltet,und sich auch um den benötigten speicherplatz usw kümmert.
diese Klasse wird dynamisch von einer containerklasse erzeugt.

die containerklasse hat die hauptaufgabe, diese texturklassen zu verwalten, und soll nicht nur doppeltes laden verhindern, sondern auch dafür sorgen, dass eine textur nur dann aus dem speicher gelöscht wird, wenn sie nicht mehr gebraucht wird.

um auf diese Textur zugreifen zu können, habe ich mich für einen smartpointer entschieden, hauptsächlich darum, damit nicht einfach auf der textur selber Release() aufgerufen wird, und somit das ganze prinzip flöten geht.

der pointer hat selber eine release funktion, die der containerklasse mitteilen soll, dass dieser pointer nun nichtmehr die textur braucht,und wenn dies der letzte zugreifen pointer war,macht sich die containerklasse daran, das ganze Texturobjekt sorgfältig zu löschen.

das problem ist nun, wie ich den release aufruf gestalten soll.
im moment ist es bei mir eher ein krampf, mein funktion pointer trägt noch einen weiteren pointer auf die containerklasse(für die release funktion) + einen string der den texturnamen enthält mit sich rum, da ich die texturen mithilfe von strings gespeichert habe.
(ich suche also über den string das richtige texturobjekt raus, und führe dann die release funktion des objekts aus)

das sind zwischen dem 3 und 4fachen speicher, den der pointer normalerweise benötigen würde, und ich bin gelinde gesagt garnicht zufrieden damit.

kennt jemand vielleicht ne gute lösung?

[tag]

Je nach Container könntest du dir doch auch einen Iterator merken; IIRC ist z.B. ein std::iterator so lange gültig, bis das Element an dieser Position gelöscht wird, er bleibt also von Einfügeoperationen unbeeinflusst. Beim Aufruf von Release schaust du nun nach, ob die Textur hinter dem Iterator noch verwendet wird und wenn nicht gibst du sie frei.