ich habe Mal wieder eine mögliche Designfrage, sprich: Ich erzähle euch, was ich hier habe und erhoffe mir Vorschläge oder Zustimmungen, ob das so gut designed scheint. Wieso? Weil ich mich laufend verbessern möchte, selbst wenn ich mein Design gerade ganz gut finde.

So, nach dem ersten Absatz sind hier sicher nur noch Leute, die an meinem "Problem" interessiert sind.

Also, ich habe meine berühmt-berüchtigte Model-Klasse, die ein geladenes 3D-Modell repräsentiert. Ein solches Modell kann einen Kollisionskörper haben (d.h. z.B. ein Baum von Sphären, die das Modell annähern), muss aber nicht! Und das soll sich der Benutzer nach dem Laden selbst aussuchen können und den Körper quasi über DI reinschmuggeln. Der Sphärenbaum wird aber nicht nur durch den ctor erstellt, sondern extern durch eine freie Funktion, da der Prozess recht aufwendig ist und insbesondere viele Hilfsstrukturen und Hilfsfunktionen genutzt werden.

Konkret muss der Benutzer jetzt Folgendes machen:

unique_ptr<Model> ehRock;
ehRock.reset(loadModel("D:/3D-Modelle/Statisch/Rock/rock_1.dae"));
ehRock->SetCollisionBody(createBoundingSphereTree(ehRock, 3));

(Bitte keine Belehrungen zu absoluten Pfaden, das ist ein reines Testprojekt, da nutze ich mein privates Modell-Reposistory, das abseits des eigentlichen Projekts liegt)

Auch das Modell wird über eine FactoryMethod geladen, da unterschiedliche Loader dahinterstecken können und das Erstellen ebenfalls ziemlich aufwendig ist.

Was mich jetzt etwas stört: loadModel und createBoundingSphereTree liefern jeweils ein mit new erzeugtes Objekt zurück. Man kann das Ergebnis in einen Smartptr verfrachten und ist zufrieden. Aber wie mache ich das meinem Benutzer klar, der meine Engine nutzt? Wenn der aufmerksam ist, wird er sich ja fragen, ob er den Speicher freigeben muss ohne zu wissen, dass Model das bereits erledigt (was ich bisher z.B. auch euch gegenüber nicht erwähnt habe).

Also wie löse ich die Problematik, dass sehr große mit new erzeugte Objekte über Funktionen zurückgegeben werden und der Nutzer das u.U. gar nicht weiß?

Auch das Modell wird über eine FactoryMethod geladen, da unterschiedliche Loader dahinterstecken können und das Erstellen ebenfalls ziemlich aufwendig ist.

Was mich jetzt etwas stört: loadModel und createBoundingSphereTree liefern jeweils ein mit new erzeugtes Objekt zurück. Man kann das Ergebnis in einen Smartptr verfrachten und ist zufrieden. Aber wie mache ich das meinem Benutzer klar, der meine Engine nutzt? Wenn der aufmerksam ist, wird er sich ja fragen, ob er den Speicher freigeben muss ohne zu wissen, dass Model das bereits erledigt (was ich bisher z.B. auch euch gegenüber nicht erwähnt habe)

Konstruktion und Destruktion müssen ja immer paarweise erfolgen. Das fängt an mit dem richtigen delete/delete[]/free zum new/new[]/malloc, hört dort aber noch lange nicht auf. Bei DLLs sollte Beispielsweise alles was in der DLL erzeugt wird, auch in der DLL zerstört werden. Wenn du die Konstruktion in einer Factory erledigst, sollte dort auch die Destruktion erfolgen. Die Factory weiß, wie sie ein Objekt konstruiert hat, muss also auch wissen, wie sie es wieder beseitigt. unique_ptr hat ein deleter-Template-Argument, d.h. du kannst dafür sorgen, dass zum Zerstören nicht delete sondern etwas anderes aufgerufen wird. Sprich: gib aus loadModel einen unique_ptr<Model, ModelLoader::unloadModel> zurück und alles ist super

Was den Returntyp der Factory angeht: unique_ptr finde ich auch gut. Es sei denn die ganze Engine arbeitet sowieso überall mit einem bestimmten Smart-Pointer, dann würde ich auch gleich genau so einen Smart-Pointer zurückgeben.

Dann noch eine Verständnisfrage: Ich hätte gedacht, der unique_ptr lässt sich nicht zurückgeben o.ä., habe jetzt aber gelesen, dass die Move-Semantik hier greift. Hätte irgendwie gedacht, das funktioniert nur für Container. Die Semantik nutzt man hier auch nur, weil man ganz klar von Kopie und Bewegung (Move) unterscheiden will/muss?

Wenn das funktioniert, gefällt mir die Variante natürlich sehr gut. Zum Löschen wird zur Zeit nichts weiter erfordert, weil das Datenladen zwar komplex ist, aber zum Entladen weit weniger Aufwand notwendig ist und dass alle Destrukturen hinbekommen.

Vielleicht noch gut zu wissen: die Hauptproblematik beim Laden besteht im Parsen von Dateien mit bestimmten Formaten. Das muss alles von Dateistruktur in Engine-Struktur (=meine Struktur) umgewandelt werden. Ist es einmal verankert ist das Ressourcen freigeben hingegen trivial.

Dann erscheint doch Folgendes ganz gut:

// ModelLoader.hpp

namespace Engine
{
    class Model;

    typedef unique_ptr<Model> ModelPtr;

    ModelPtr createModel(/* ... */);
}

Jetzt kann ich nachträglich noch einen Deletor einfügen, falls ich ihn denn wirklich brauchen sollte, wovon ich aber nicht ausgehe. (Und jetzt könnte die Diskussion zwischen euch (hustbaer und pumuckl) diesbzgl. wieder einsetzen :))

Dann noch eine Verständnisfrage: Ich hätte gedacht, der unique_ptr lässt sich nicht zurückgeben o.ä., habe jetzt aber gelesen, dass die Move-Semantik hier greift. Hätte irgendwie gedacht, das funktioniert nur für Container. Die Semantik nutzt man hier auch nur, weil man ganz klar von Kopie und Bewegung (Move) unterscheiden will/muss?

Nein, es funktioniert nicht nur für Container. Move-Semantik macht bei allem sinn, was irgendeine Ressource weitergeben will, d.h. A hat die Ressource und gibt sie an B weiter. Im Fall von Containern ist das der Speicher mit dem Inhalt der Container, damit nicht alles kopiert und sofort das original weggeworfen wird. Beim unique_ptr ists der Speicher mit dem enthaltenen Objekt, der darf nicht kopiert werden. Beim unique_ptr ist genau einer der Besitzer des Objekts auf dem Freispeicher. Kopieren ist daher verboten, sonst wären zwei die Besitzer oder es wäre eine unechte Kopie wie beim auto_ptr. Move-Semantik ist hier genau das Richtige, der Besitz vom einen unique_ptr wird an den nächsten weitergeschoben.

Wenn das funktioniert, gefällt mir die Variante natürlich sehr gut. Zum Löschen wird zur Zeit nichts weiter erfordert, weil das Datenladen zwar komplex ist, aber zum Entladen weit weniger Aufwand notwendig ist und dass alle Destrukturen hinbekommen.

Vielleicht noch gut zu wissen: die Hauptproblematik beim Laden besteht im Parsen von Dateien mit bestimmten Formaten. Das muss alles von Dateistruktur in Engine-Struktur (=meine Struktur) umgewandelt werden. Ist es einmal verankert ist das Ressourcen freigeben hingegen trivial.

Dann erscheint doch Folgendes ganz gut:

// ModelLoader.hpp

namespace Engine
{
    class Model;

    typedef unique_ptr<Model> ModelPtr;

    ModelPtr createModel(/* ... */);
}

Jetzt kann ich nachträglich noch einen Deletor einfügen, falls ich ihn denn wirklich brauchen sollte, wovon ich aber nicht ausgehe. (Und jetzt könnte die Diskussion zwischen euch (hustbaer und pumuckl) diesbzgl. wieder einsetzen :))

So in der Art hätte ichs mir auch vorgestellt. Den Deletor einzufügen ist trivial: einfach eine entsprechende Funktion schreiben und sie in den typedef mit aufnehmen. Wenn mehrere Objekte eine Referenz auf das selbe model haben können sollen ließe sich das noch ändern in shared/weak_ptr. Auch die haben deleter...