spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

In welchem Kontext soll das ganze denn eingesetzt werden? Geht es um Ressourcen-Verwaltung? Dann ist die Frage, was du mit der unique-Ownership erreichen möchtest?
Willst du anderen einfach den Zugriff auf die Ressourcen unterm Hintern wegziehen ? Also aus welchem Grund überlebt die Referenz auf die Resource den die Ressource?

Darf ich fragen, wieso bei dir ein unique_ptr zerstört wird, bevor alle Leute, die das damit verbundene Objekt benutzen zerstört wurden? Wenn das bei dir der Fall ist, dann solltest du besser dein Design dahingehend fixen, dass das eben nicht mehr passeren kann, denn offenbar liegt der Besitz des Objektes eindeutig an der falschen Stelle...

Zitat von »Evrey«

unique_ptr ist zu nutzen, wenn _nur_einer_ gleichzeitig ein Objekt verwenden darf, ungeachtet davon, wer sich ums Aufräumen kümmert.

shared_ptr/weak_ptr ist dann zu nutzen, wenn mehrere gleichzeitig ein Objekt verwenden dürfen, aber jeder dieses Objekt zu jeder Zeit benutzen darf.[/align]

Nope, wie hier ja schon erklärt wurde, sind Nutzung und Besitz sind zwei grundverschiedene Dinge und Smartpointer rein prinzipiell nur für letzteres zuständig. unique_ptr ist zu nutzen, wenn es genau einen eindeutigen Besitzer für ein Objekt gibt, was mit Abstand den Großteil aller Obekte ausmacht und shared_ptr ist für den extrem seltenen Randfall, dass man geteile Besitzverhältnisse braucht, was man fast nie sollte...

Zitat von »Evrey«

Der Anwendungs-Fall ist folgender:
owned_ptr/borrowed_ptr ist dann zu verwenden, wenn ein Objekt (z.B. ein Manager) explizit Objekte besitzt, die von anderen benutzt werden dürfen, deren Verwendung allerdings über die Lebenszeit des Besitzers hinweg keinen Sinn ergibt. Das kann z.B. ein OpenAL-Buffer sein, der nur so lange zu verwenden ist, wie der OpenAL-Kontext existiert. Generell bei _allen_ Objekten, zu deren Dokumentation irgendwas wie "Don't use unless this/that..." oder "Don't delete, because..." steht.

Ok in dem Fall würde ich sagen, dass es keine allgemein gültige Lösung gibt, jedenfalls nicht ohne Annahmen darüber zu machen, wie die Objekte benutzt werden. Das liegt daran, dass ich in diesem Beispiel davon ausgehen muss, dass der Al-Buffer (oder allgemein ein Objekt) jederzeit ungültig werden kann, weil sein Kontext-Objekt ( in diesem Fall der Al-Kontext) jederzeit vernichtet werden kann. Mit jederzeit meine ich wirklich zu jeder Zeit, also auch während ich auf dem Objekt operiere (z.b. beim Multithreading). Ich muss also schonmal irgendwelche Annahmen machen:

1. Das Objekt wird nicht ungültig, nur weil sein Kontext-Objekt verschwindet: Das wäre dann ja ein typischer Fall für den shared_ptr/weak_ptr. Dann hat man halt kurze Zeit ein Zombie-Objekt rumfliegen oder kann es noch weiter Benutzen, weil das Kontext-Objekt halt nicht benötigt wird (z.b bei einem Bild welches im Speicher liegt). Der Fall ist ja hier eher nicht gemeint und eher uninteressant.

2. Das Kontext-Objekt überlebt in jedem Fall alle Zugriffe auf seine Objekte: Der Fall ist auch einfach. Wir benutzen einen unique_ptr im Kontext-Objekt und geben raw pointer weiter (oder ne Kapselung, damit man auf keinen Fall delete aufrufen kann).

3. Das Kontext-Objekt wird vernichtet, während niemand auf seine Objekte zugreift: Das ist schon eine harte Annahme, kann aber in einer Single-Threaded-Umgebung durchaus leicht umzusetzten sein (das Objekt darf sich selbst oder das Kontext-Objekt halt unter keinen Umständen selbst vernichten (z.b. über Callbacks oder so)). In dem Fall könnte man diesen Pointer aus deiner zweiten Variante nehmen + expired-Methode. Oder halt weak_ptr + shared_ptr und im Kontext könnte man dann noch ein assert(ptr.unique()) machen.

Wenn ich keine dieser Annahmen mache, muss ich immer damit rechnen, dass das Objekt noch benutzt wird, während jemand auf es zugreift.

Zitat von »Evrey«

Der Anwendungs-Fall ist folgender:
owned_ptr/borrowed_ptr ist dann zu verwenden, wenn ein Objekt (z.B. ein Manager) explizit Objekte besitzt, die von anderen benutzt werden dürfen, deren Verwendung allerdings über die Lebenszeit des Besitzers hinweg keinen Sinn ergibt. Das kann z.B. ein OpenAL-Buffer sein, der nur so lange zu verwenden ist, wie der OpenAL-Kontext existiert. Generell bei _allen_ Objekten, zu deren Dokumentation irgendwas wie "Don't use unless this/that..." oder "Don't delete, because..." steht.

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...

Zitat von »Evrey«

unique_ptr ist zu nutzen, wenn _nur_einer_ gleichzeitig ein Objekt verwenden darf, ungeachtet davon, wer sich ums Aufräumen kümmert.

shared_ptr/weak_ptr ist dann zu nutzen, wenn mehrere gleichzeitig ein Objekt verwenden dürfen, aber jeder dieses Objekt zu jeder Zeit benutzen darf.

Nope, wie hier ja schon erklärt wurde, sind Nutzung und Besitz zwei grundverschiedene Dinge und Smartpointer rein prinzipiell nur für letzteres zuständig. unique_ptr ist zu nutzen, wenn es genau einen eindeutigen Besitzer für ein Objekt gibt, was mit Abstand den Großteil aller Obekte ausmacht und shared_ptr ist für den extrem seltenen Spezialfall, dass man geteile Besitzverhältnisse braucht, was man fast nie sollte...

Zitat von »Glocke«

@dot: Die "Designfehler"-Keule liegt immer griffbereit Aber wie gesagt: Das Dungeon besitzt das Objekt und die KIs kennen/verwenden es. Ich sehe an diesem Design beim besten Willen keinen Fehler

Leider verrätst du nicht genug über das Problem, das lösen zu müssen du meinst, um hier viel sagen zu können. Ich bin mir allerdings sicher, dass sich ein besseres Design, in welchem dieses Problem von vorn herein nicht auftritt, finden ließe...

Zitat von »Glocke«

Und shared ownership schließe ich mach wie vor (und in Anbetracht der Testergebnisse auch weiterhin) als Lösung aus.

Und diese Tests sind auch im Release Build gefahren? Performancemessung eines Debug Build ist leider ein witzloses Unterfangen...
Selbst dann sagen die Werte nicht viel über die praktischen Implikationen aus. In einer realen Anwendung werden die aufgerufenen Funktionen den Großteil der Laufzeit ausmachen, sodass der Overhead des Aufrufs an sich sehr schnell vernachlässigbar wird...

Also eine VC-Performance-Analyse sagt, dass die 77,7% der Gesamtlaufzeit des Programms dabei draufgeht weak_ptr::lock aufzurufen. Sonst brauchen alle Aufrufe fast gleich viel Zeit.
Wie erwartet ist das locken der weak_ptr das was am längsten dauert. Ich denke aber weak_ptr wird in deinem Design auf keinen Fall benötigt.

Außerdem müssen die Tests außerhalb von einer IDE wie Visual Studio durchgeführt werden. In Visual Studio sind Allokationen nämlich unverhältnismäßig langsam. Faktor 10 habe ich noch im Kopf, ich weiß aber nicht, ob das (noch?) stimmt.

Außerdem würde ich ggf. auch "std::make_shared" testen. (Warum? Siehe bereits von mir verlinkte Diskussion auf Zfx.)
Dieser Pointer ist außerdem im Gegensatz zu deiner Klasse Threadsicher.

@Evrey
Dein Vorschlag wäre theoretisch vom naiven Speicherverbrauch und wahrscheinlich in den meisten Fällen von der Performance überlegen.
Leider gibt es dadurch ein von den "usable_borrowed_ptr", wie du es nennst, ein "Speicherleck"(nicht ganz im engeren Sinn). Es kann auch nach Ende der Lebensdauer des Objektes nicht aller Speicher freigegeben werden. Die" Zombieobjekte" im Heap können erst freigegeben werden, wenn auch alle Pointer die eigentlich nicht Besitzer sind, zerstört wurden.

EDIT:

Zitat von »Databyte«

Ich denke aber weak_ptr wird in deinem Design auf keinen Fall benötigt.

Eigentlich ist das das ganze was ihn interessiert. Er will doch ein "std::unique_ptr" mit "std::weak_ptr" im Prinzip.