Auf Member eines zerstörten Objektes zugreifen funktioniert

Sone

Funktioniert nicht heißt, Absturz, der sogar einen Kaltstart erfordern kann.
Natürlich kann ich kein kompilierbares Beispiel vorführen, aber dots Antwort war eigentlich schon perfekt. Es kann gut sein, dass im Destruktor von mRigidBody auf einen Member wie die Scenenode zugegriffen werden kann, also darf es davor nicht zerstört werden. Wenn aber der Speicher gültig bleibt...

Lösung: Davor Zeiger auf Scenenode (die btw. unabhängig von meinem zu zerstörenden mRigidBody existiert) nehmen, zerstören und anschließend mit Zeiger arbeiten.

Danke für die Hilfe

Sone

so:

Ogre::SceneNode* scnptr = ch.mRigidBody->getSceneNode();
        delete ch.mRigidBody;
        scnptr->getParentSceneNode()->removeAndDestroyChild(scnptr->getName());

Funktioniert, dürfte immer funktionieren.

dot

*snip*

TyRoXx

if(vecPos != sceneObjects.end())
                Singleton.sceneObjects.erase(vecPos);

Die Abfrage ist nicht nötig.
Singletons sind Mist.
Singleton.sceneObjects ist dasselbe Objekt wie einfach sceneObjects ?

delete ch.mRigidBody; // <<- Hier

delete benutzt man nicht.
Wie kommst du eigentlich auf die Idee, eine Ressource einer fremden Klasse zu löschen?

Hacker schrieb:

P. S.: Ich übergebe keine Referenz, weil SceneObject nur zwei Pointer als Member hat, also so groß wie ein long sein dürte... :d

Seltsame Rechnung:
sizeof(void *) = 8
sizeof(long) = 8
2 * 8 != 8

Sone

1. Ja, da hab ich mich mit den Pointergrößen verrechnet. Übrigens ist bei meinem Compiler ein Zeiger 4 Bytes groß, ich kompiliere mit einem 32-Bit MinGW.
2.

Wie kommst du eigentlich auf die Idee, eine Ressource einer fremden Klasse zu löschen?

Wie kommst du darauf dass das eine fremde Klasse ist? Es ist eine von mir erstellte Datenstruktur, die wegen Punkt 4 nicht selber Speicher freigeben darf

3. Die Funktion dessen Code ich gezeigt habe ist keine Memberfunktion der Klasse des Singletons. Überhaupt: Singletons sind Mist ist keine Aussage. Ich finde, es ist ein sinnvolles Designpattern, und Designkritiken wollte ich auch gar nicht.

4. Ich kann delete so benutzen wie ich will. Ich muss selbst über die Lebenszeiten der Objekte entscheiden, weil sie sich sonst in die Quere kommen.
Also gehen weder Smart-Pointer noch Boosts Pointer-Container. Aber da bin ich mir nicht sicher, ich muss immer an refactoring denken.

der code ist ja schrecklich

otze

Hacker schrieb:

3. Die Funktion dessen Code ich gezeigt habe ist keine Memberfunktion der Klasse des Singletons. Überhaupt: Singletons sind Mist ist keine Aussage. Ich finde, es ist ein sinnvolles Designpattern, und Designkritiken wollte ich auch gar nicht.

Singleton ist eine Krankheit und kein Designpattern. Insbesodnere gilt es als Paradebeispiel eines Antipatterns.

Sone

auto vecPos = std::find(sceneObjects.begin(), 
                                sceneObjects.end(), 
                                ch); 
        if(vecPos != sceneObjects.end()) 
                Singleton.sceneObjects.erase(vecPos);

Klar, das ist hässlich.

std::remove(sceneObjects.begin(),
                    sceneObjects.end(),
                    ch);

Ich refactore gerade alles auf std::unique_ptr .

Sone

Edit: lol. Der obige Code ist peinlich falsch...

Shame on me.

Sone

So, bin fertig. Und das Ergebnis des refactoring ist mehr als befriedigend: viele Zeilen Code verloren, die Klasse SceneObject brauche ich gar nicht mehr, und die Speicherfreigabe ist jetzt sicher mit einem Pointer Container und ein oder zwei unique_ptr s.

Danke!
Ich werde mich das nächste mal ohrfeigen, wenn ich wieder delete in meinem Code schreibe .