Destruktor aus Memberfunktion aufrufen?

asc

destrict0r schrieb:

Ist folgendes erlaubt?

Auf Grund der potentiellen Probleme (z.B. delete auf Stackobjekt etc.) bleibt aber die Frage, ob es für deinen Fall nicht etwas besseres gibt. Vielleicht beschreibst du erst einmal wozu du es brauchst.

T wird mit new erzeugt.

T ist eine Spieler-Klasse, die mit "t->hallo()" geupdated wird. Wenn sie in "hallo" feststellt, dass sie z.B. mit dem Feind kollidiert ist, soll sie sich selbst löschen.

Nexus

destrict0r schrieb:

Wenn sie in "hallo" feststellt, dass sie z.B. mit dem Feind kollidiert ist, soll sie sich selbst löschen.

Ganz selbst löschen kann sie sich eh nicht, da sie wahrscheinlich in einem Container steckt oder durch eine andere Variable im Programm referenziert wird. Also musst du diesen Verweise noch entfernen. Und dann kannst du gleich das delete ausserhalb schreiben.

Generell sollte Anforderung und Allokation möglichst symmetrisch sein. Wenn jemand das Objekt mit new erstellt, sollte er (und nicht irgendwer sonst) es wieder zerstören. Falls du dann mal was änderst, musst du das nur an einer Stelle tun. Oder noch besser, du nimmst gleich Smart-Pointer und brauchst gar kein delete .

[quote="Nexus"]

destrict0r schrieb:

Und dann kannst du gleich das delete ausserhalb schreiben.

Und wo außerhalb? Und woher soll das außerhalb wissen, dass der Spieler getroffen wurde?

Ich dachte, dass ich einen CollisionObjectManager habe, über den alle Kollisionsobjekte erzeugt/gespeichert/gelöscht werden. Und alle Kollisionsobjekte haben eine "update"-Funktion. Könnte ich nicht aus der die Löschroutine des Managers mit this als Parameter aufrufen?

destrict0r schrieb:

Und wo außerhalb? Und woher soll das außerhalb wissen, dass der Spieler getroffen wurde?

boost::ptr_vector<T> myTs;
...
t->hallo();
if ( t->isDead() )
    myTs.erase( t );

Oder so. Irgendwo "außerhalb" hast du ja das Objekt noch gespeichert. Wenn du es in "hallo" destruierst, kriegt der Speichernde das ja nicht mit und versucht weiterhin, darauf zuzugreifen.

Oder soll ich lieber in der update-Routine ein Flag des CollisionObjekts "isDeleted" auf true setzen und dann von außen im Manager über alle CollsisionObjects iterieren und sie ggf. löschen?

drakon

isDeleted ist ungünstig. Nimm besser etwas, was den Zustand des Objektes beschreibt. Der, der das Objekt erzeugt hat kann dann entscheiden ob er es zerstören möchte oder doch lieber noch behalten.
Das Objekt soll seinem Besitzer nicht vorschreiben was er damit zu tun hat, sondern ihn nur darüber informieren, was mit ihm los ist. Was dann damit passieren soll liegt (sowieso) beim Besitzer.

Also sowas wie "isDestroyed"? Dann ist mein Vorschlag OK?

volkard

isDead oder isAlive sieht man alle Nase lang.

hasCollided könnte doch auch gehen, wenn das die Semantik ist. Manche Sachen überstehen ja vielleicht auch mehrere Kollisionen.

volkard

fdfdg schrieb:

hasCollided könnte doch auch gehen, wenn das die Semantik ist. Manche Sachen überstehen ja vielleicht auch mehrere Kollisionen.

Das verbessert nur wenig.

boost::ptr_vector<T> myTs;
...
t-> hallo( );
if (  t-> hasCollided( )  )
    if (  t-> isDead( )  )
        myTs. erase( t );

drakon

Collided ist auch nicht gut. Das ist eher ein Event. Denn normalerweise passieren ständig Kollisionen (mit dem Bode, einem Mitspieler, einem Objekt usw.). Das bedeutet in den meisten Fällen noch nicht, dass das Objekt gestorben ist. isDead, isAlive finde ich gut.

Was ist der Vorteil von ptr_vector<T> gegenüber vector<T*>?

314159265358979

Er ruft delete für dich auf.

Nexus

destrict0r schrieb:

Was ist der Vorteil von ptr_vector<T> gegenüber vector<T*>?

Automatische Aufräumung (kein delete notwendig), Exceptionsicherheit und direkte Dereferenzierung ( *itr ist T& und nicht T* ).

Ausführlich sind die Vorteile hier aufgelistet.

314159265358979 schrieb:

Er ruft delete für dich auf.

Wann?

destrict0r schrieb:

314159265358979 schrieb:

Er ruft delete für dich auf.

Wann?

Sobald du das Objekt aus dem Container entfernst, mit container.erase(iter) .

Zu beachten: Im Unterschied zu std::vector<T*> werden die Objekte aber kopiert, wenn du den Container kopierst! Oft will man das aber nicht. Um ungewolltes Kopieren zu vermeiden, kannst du deine Klasse T nicht-kopierbar machen, z.B. von boost::noncopyable erben lassen.

asc

fdfdg schrieb:

Zu beachten: Im Unterschied zu std::vector<T*> werden die Objekte aber kopiert, wenn du den Container kopierst! Oft will man das aber nicht...

Wobei man fairerweise sagen muss, das viele sich keine Gedanken über den Kopieraufwand machen - und das in beide Richtungen (Die einen die grundsätzlich alle Kopien vermeiden wollen, und dies auch an Stellen wo Kopien unproblematisch sind, als auch die, die Kopien auch dort einsetzen wo man massiv sparen könnte).

Bevor ich auf einen std::vector<T*> zurückgreife, würde ich zumindest die ptr-Container von Boost in betracht ziehen (Sofern der Container auch der Besitzer sein soll).