spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zum speichern ansich benutze ich eh nur noch und für alles unique_ptr. Alleine schon, weil man dadurch schon am Typ sieht, ob eine Klasse ein Objekt verwaltet, oder nur eine Referenz darauf.

Der shared_ptr bringt dir glaube ich nicht viel. Du musst dich halt fragen, ob zu dem Zeitpunkt, an dem der Manager zerstört wird, irgendein Objekt noch eine Ressource gespeichert hat - wenn dein Level vor dem Ressourcenmanager zerstört wird (wieso solltest du den Manager zerstören, während es noch ein Level gibt, dass Ressourcen von ihm benutzt?) wird das eh immer der Fall sein. Du hast also einfach eine Menge Verwaltungsaufwand, der dir am Ende nichts bringt.
Was die Idee mit den Handles bringen soll, versteh ich ehrlich gesagt nicht, willst du dir anhand eine Handels ständig die Ressource neu holen?
Und eine Proxyklasse, nun, welchen Mehrwert hätte die genau? Es macht keinen Sinn, dein Programm durch weitere Klassen komplexer zu machen, nur weil es "cool aussieht". Entweder du hast eine klare Notwendigkeit und wirst dieser durch eine Klasse gerecht, oder du hältst es so einfach wie möglich (was immer der bessere weg ist).

Ich würde intern unique_ptr benutzen (alleine weil die so super mit stl-Containern zusammenarbeiten) und nach außen ganze normale Pointer rausgeben (von mir aus auch Ressourcen), bis du einen wirklichen Grund hast, warum du irgendetwas anderes brauchen solltest.

Würde ich auch so machen. Ganz klare Ownership mit unique_ptr und alle anderen erhalten nur einen Raw-Pointer als Referenz. Den können sie natürlich mutwillig löschen, aber mehr als einen Fehler wird das nicht bewirken. Programme absichtlich zum Absturz bringen kann ein Entwickler immer. Also lautet die Regel ganz klar: Was dir nicht gehört, darfst Du nicht löschen. Im Foren-Spiel wird das ganz restriktiv so gehandhabt. Raw-Pointer sind nur Referenzen, ein Delete gibt es nirgends, das machen alles unique_ptr.

Ok, was du zumindest tun könntest, wäre ein typedef für den Zeiger zu benutzen. Willst du später auf Proxy-Objekte umsteigen, brauchst du bei denen nur den -> Operator überladen und solltest den meisten Code ganz normal weiter benutzen können.

Durch Reference-Counting kannst du zum Beispiel feststellen, ob Ressourcen noch benutzt werden, oder aber freigegeben werden können. Allerdings musst du dich fragen, ob sich das für dich lohnt:
- Eventuell hast du gar nicht so viele Objekte, dass du zur Laufzeit welche freigeben musst, um platz für neue zu schaffen
- Es ist relativ wahrscheinlich, dass Dinge die einmal benötigt werden auch noch ein weiteres mal benötigt werden
- Wenn Wenn du ein neues Level lädst, und das vorherige vorher löschst, sind eh alle Ressourcen weg, dann kannst du auch einfach beim Laden einen neuen Manager anlegen und hast damit auch aufgeräumt. Um Objekte wirklich wiederverwenden zu können, musst du dir etwas einfallen lassen, Beispielsweise das neue Level laden, bevor du das alte freigibst, oder ein verzögertes freigeben, dass die Objekte noch am Leben lässt, auch wenn der Referenzcounter auf 0 ist.

Es kann also durchaus Sinn machen, trivial ist die Angelegenheit aber nicht.
Aber was auch Klasse ist: Du kannst Proxyobjekte haben, die zur Laufzeit ihre Ressource wechseln, ohne dass der Benutzer etwas merkt. So kannst du beispielsweise sehr niedrig aufgelöste Texturen zum Start laden und dann in einem zweiten Thread während das Spiel schon läuft, bessere Versionen nachladen. In Bioshock sieht man das zuweilen sehr deutlich. Der Vorteil ist, dass wenn diese Ressourcen nicht direkt am Levelstart sichtbar sind, es dem Benutzer gar nicht auffällt, er hat nur kürzere Ladezeiten. Und sollte er sie doch mal sehen, sieht er halt ein paar Sekunden eine schlechtere Version, was noch verhältnismäßig harmlos ist.

Wie gesagt, für den Anfang ist ein normaler Zeiger eigentlich ok, aber mit einem typedef kannst du dir etwas Arbeit ersparen, solltest du irgendwann mal etwas von dem Erwähnten umsetzen wollen.

Es ist natürlich Ansichtssache, aber ich persönlich mag es nicht wenn mir Pointer zurückgegeben werden. Man weiß nie ist es jetzt eine Referenz oder nicht. Am Ende wird etwas erzeugt und nie frei gegeben. Bei den shared_ptr kannst du z.B. einen Deleter übergeben. Soll die Ressource freu gegeben werden so kannst du den normalen benutzen, soll das nicht so sein kann dein Manager einen anbringen der die Resource dann selbst zerstört oder einfach nichts tut. Durch den weak_ptr hättest du dann sogar eine Möglichkeit festzustellen ob die Resource noch benutzt wird.

Diese Idee kommt aber bei mir aus einem anderen Bereich, ich habe sowas in der Form deiner Fragestellung noch nicht umgesetzt.
Für mich ist aber der Stern böse fui bäh.




Edit:
Hab noch mal hinzugefügt wie ich eine Resource erzeugen würde die der Manager nicht verwaltet. Auch wenn es ein größeres Object sein sollte… der Compiler macht das schon. Man braucht nur noch selten Zeiger.

Nein, der Stern muss schon in den Typedef mit rein. Sonst legst du dich ja wieder auf Pointer fest und wirst nie Proxyobjekte benutzen können, höchstens Pointer auf Proxyobjekte.