3. Smartpointer Problem

Smartpointer Problem

  • R

    Hi,

    danke für den Code.

    Was gibts denn für Alternativen zu Gamestates? Ich will natürlich weiter dazulernen 😉

    Gruß

    0
  • M

    Gamestates ueber abstrakte Klassen verteilen sieht mir sehr nach overengeneering aus, denn ueblicherweise ist das eine einfache FSM.
    Meistens hat man ein enum fuer die ganzen Zustaende, die GameState-Klasse empfaengt events und ruft dann ueber ein switch die richtige Funktion auf. Das ist sehr viel konkreter und Funktionalitaet laesst sich leichter ergaenzen.

    0
  • R

    Hi,

    werden bei unique_ptr irgendwie bei der Initialisierung schon Objekte angelegt und wieder gelöscht?
    Ich habe das Problem, dass bei der Initialisierung Destruktoren von Objekten aufgerufen werden, die eigendlich noch garnicht existieren dürften.
    Diese Objekte sind nicht richtig initialisiert (vielleicht weil sie keinen Default-Konstruktor habe), deshalb gibts beim Löschen wieder Probleme.

    Gruß

    0

  • Raven280438 schrieb:

    werden bei unique_ptr irgendwie bei der Initialisierung schon Objekte angelegt und wieder gelöscht?

    Hängt davon ab, ohne deinen Code zu sehen, kann man das nicht sagen...

    0
  • ?

    Raven280438 schrieb:

    werden bei unique_ptr irgendwie bei der Initialisierung schon Objekte angelegt und wieder gelöscht?

    Nicht die Typen, auf die der Zeiger zeigt. Intern werden natürlich schon Objekte erzeugt.

    0
  • J

    manni66 schrieb:

    Intern werden natürlich schon Objekte erzeugt.

    Ist das so 'natürlich'? Was soll denn da erzeugt werden?

    0
  • ?

    Jockelx schrieb:

    manni66 schrieb:

    Intern werden natürlich schon Objekte erzeugt.

    Ist das so 'natürlich'? Was soll denn da erzeugt werden?

    Der unique_ptr selber?

    0

  • Jockelx schrieb:

    manni66 schrieb:

    Intern werden natürlich schon Objekte erzeugt.

    Ist das so 'natürlich'? Was soll denn da erzeugt werden?

    beispielsweise der Deleter... 😉

    0
  • J

    Mmh, ok, hab irgendwie aus dem 'no-size-overhead' geschlossen, dass da nichts erzeugt wird.
    Aber auch ein leerer Deleter muss ja erzeugt werden.

    0
  • R

    Hi,

    im Detail:

    Ich habe 2 Klassen:

    class Primitives::Triangle : public IRenderable
{
[...]
];

class TestApp::TestState
{
private:
std::unique_ptr<Primitives::Triangle> Triangle;
[...]
};

    Im Konstruktor der TestState-Klasse wird das Triangle erzeugt:

    this->Triangle = std::unique_ptr<Primitives::Triangle>(new Primitives::Triangle(glm::vec3(50, 100, 0), glm::vec3(100, 50, 0), glm::vec3(150, 100, 0)));

    Durch Breakpoints hab ich rausgefunden, es wird zuerst der Kontruktor der Triangle-Klasse aufgerufen, dann sofort wieder der Destruktor.
    Beim Beenden des Programms wird dann nochmal der Destruktor der Triangle-Klasse aufgerufen, was zu Problemen führt.

    Liegt das an dem unique_ptr, oder hab ich irgendwo anders im Programm einen Fehler?

    Gruß

    0

  • Wieso muss das Triangle überhaupt mit new erzeugt werden, wieso nicht einfach

    class TestApp::TestState
{
private:
 Primitives::Triangle Triangle;
[...]
};

    Raven280438 schrieb:

    Durch Breakpoints hab ich rausgefunden, es wird zuerst der Kontruktor der Triangle-Klasse aufgerufen, dann sofort wieder der Destruktor.
    Beim Beenden des Programms wird dann nochmal der Destruktor der Triangle-Klasse aufgerufen, was zu Problemen führt.

    Das ist sehr merkwürdig, kann es sein, dass der TestState gleich wieder zerstört wird? Und wieso führt das du Problemen?

    0
Anmelden zum Antworten