spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

Da würd ich nun doch erst nochmal schwer drüber nachdenken, wieso es denn zu dem Zustand kommen können sollte, dass Objekte, die OpenAL Buffer verwenden, den OpenAL Kontext überleben und wofür genau dieser Manager eigentlich gut ist...

Das Beispiel ist jetzt nicht das beste gewesen, aber es kann durchaus Anwendungsfälle geben, in denen das passieren darf. Eine Ressource kann ja zwischenzeitlich wegsterben, aber das hindert einen ja nicht daran, im Falle einer Exception eine neue anzufordern und damit weiter zu arbeiten.

Diese Anwendungsfälle mögen rar sein, und ich bin der Ansicht, dass der Anwendungsfall von Glocke eher ein Fall für ein alternatives Design ist, aber rar ist nicht gleich nie. shared_ptr und weak_ptr haben auch lediglich seltene Anwendungsfälle, vor allem weak_ptr, der eigentlich bloß Zirkelschlüsse aufbrechen soll. Aber für den Fall, dass man sie braucht, gibt es sie dann doch im Standard.

Zitat

Die" Zombieobjekte" im Heap können erst freigegeben werden, wenn auch alle Pointer die eigentlich nicht Besitzer sind, zerstört wurden.

Das ist tatsächlich ein nicht zu unterschätzendes Problem, zumal es während all' dieser Zeit den Destruktor-Thread blockiert. Allerdings ist das dann eher ein Fall von Design-Fehler beim Nutzer. Wenn man sich ein Objekt in dem Sinne nur "mal eben ausleiht", sollte es nicht vorkommen, dass ein usable_borrowed_ptr lange existiert. Immerhin wird man da vorm plötzlichen Wegsterben geschützt. Mit unique_ptr<T> und T* allein gibt es diese Blockade nicht. Stirbt die Ressource also während der Verwendung in einem anderen Thread weg, kommt es im Raw Pointer -Thread plötzlich zu einem Crash oder seltsamen Undefined Behavior, weil man mit gelöschtem Speicher arbeitet. Viel Spaß bei der Fehlersuche. Das funktioniert natürlich auch ohne Threads. Und unique_ptr kann wie gesagt den Fall nicht modellieren, in dem die Ressource zwischenzeitlich sterben darf.


@Perftest:
Wie es so schön heißt: Wer misst, misst Mist. Es ist ein Unterschied, ob du die Performance eines winzigen API-Teils isoliert misst, oder alles zusammen im Kontext deiner spezifischen Software. Das sieht so erstmal beeindruckend aus, aber es ist sehr wahrscheinlich, dass diese "langsamen" Operationen im Gesamtprogramm so selten vorkommen, dass du den "Performance-Verlust" nicht einmal bemerkst. Selbstverständlich bringen shared_ptr und weak_ptr einen Overhead gegenüber unique_ptr und T* mit, sobald irgendwas durch die Gegend kopiert oder locked wird. Aber das bisschen Overhead ist den Gewinn durch Robustheit der Anwendung (selbst bei Multithreading) alle Male wert.

Wie angemerkt, ist owned_ptr dann ratsam, wenn eine Ressource einen speziellen Besitzer hat, aber von mehreren genutzt werden darf, wobei der Besitzer zwischenzeitlich sterben und aufräumen kann. Wenn man die Möglichkeit hat, kann man das Problem umgehen, indem man nicht die Ressource ausleiht, sondern den Besitzer besitzt. Dann ist alles eine herkömmliche shared_ptr/weak_ptr-Kette und es ist gewährleistet, dass - wer auch immer den Besitzer löscht - der Besitzer die Ressource entfernt und niemand sonst. Natürlich setzt das voraus, dass es im Sinne des Programms ist, dass mehrere den Besitzer besitzen.