Ressourcen-Verwaltungsklasse

Nexus

Dravere schrieb:

In dem du sie gar nicht erst in einem Schlüssel vereinst.
[...]
Über das erste Kriterium und dem ersten Container kommst du an einen zweiten Container, worauf du das zweite Kriterium anwenden kannst.

Du meinst also eine Abbildung der Art

ID -> Grösse -> Ressource

statt

(ID, Grösse) -> Ressource

, implementiert durch verschachtelte Container? Okay, das wäre auch eine Möglichkeit. Nach der ID suchen kann man aber so immer noch nicht eindeutig, da möglicherweise mehrere Grössen damit assoziiert sind.

Dravere schrieb:

Die Definition hier ist einfach noch viel zu wage.

Das mag stimmen, aber bevor ich mich mit den Details befasse, will zuerst ein grobes Konzept fürs Gesamtdesign haben. Es bringt nichts, wenn mir schon eine fertige Implementierung vor Augen schwebt, die sich dann doch nicht in den Rest integrieren lässt.

Dravere schrieb:

Die Frage ist, ob du auch wieder mal alles über einen Kamm ziehen willst. Die Ressourcenverwaltung von einem GUI kann nun mal ziemlich anders aussehen als jene von einem Spiel.

Naja, es gibt einige Gemeinsamkeiten. Statt Schaltflächen handelt es sich vielleicht um Sprites, und es kommen noch zig andere Ressourcen dazu. Ich wollte das einigermassen generisch lösen, um nicht für jeden Anwendungsfall eine neue ResourceManager-Klasse benutzen zu müssen.

Dravere schrieb:

Wenn jede GUI-Komponente sich einmal selber zeichnet und danach den eigenen Cache verwendet, wäre dies vielleicht nicht die schnellste Lösung, aber immer noch absolut ausreichend. Dafür ist aber die Logik dazu deutlich einfacher.

Es kann ja sein, dass das Laufzeitverhalten bei ein paar wenigen Schaltflächen nicht ins Gewicht fällt. Aber bei einem komplexeren Spiel können durchaus viele, teilweise grosse Bilder/Texturen geladen werden – neben Soundeffekten, Musik-Streams, evtl. 3D-Modellen etc. Da lohnt es sich schon, keine Ressourcen zu duplizieren.

Übrigens, bei einer einzelnen GUI-Komponente von Caching zu sprechen, halte ich für übertrieben.

Nexus

Falls es jemanden interessiert, ich habe eine vorläufige Lösung gefunden. Vielleicht stolpert ja jemand über diesen Thread und kann irgendwas davon brauchen. Auf jeden Fall vielen Dank für alle Inspirationen in diesem Thread.

Und zwar habe ich den ResourceManager als Template implementiert, sodass er für beliebige Ressourcen verwendet werden kann. Er bietet nun hauptsächlich die Methoden Acquire() , Search() und Release() wie gehabt an. Um die Ressourcen anzusprechen, benutze ich Key-Klassen. Diese enthalten Ladeinformationen (z.B. Pfad oder Grösse beim Bild) und eine optionalen String-ID. Ich habe dazu zuerst einen Typ-Tag wie bei Boost.Flyweight genommen, jedoch hat es sich als zu wenig flexibel herausgestellt, den Tag zur Kompilierzeit zu kennen.

Wenn jemand nun Acquire() aufruft, erhält er einen ResourcePtr . Dabei handelt es sich um einen Smart-Pointer mit zentraler Referenzzählung, ähnlich wie Draveres resource_slot . Zudem werden alle ResourcePtr -Instanzen auf NULL gesetzt, wenn die entsprechende Ressource freigegeben wird. Was ich auch noch gemacht habe, ist Const-Correctness zu implementieren, sodass ResourcePtr<const Resource> von ResourcePtr<Resource> konstruiert werden kann und ein konstanter ResourceManager nur Const-Zeiger zurückgibt.