Destruktor aus Memberfunktion aufrufen?

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

Nexus

fdfdg schrieb:

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

Noch viel weniger will man aber std::vector<T*> kopieren, falls die Zeiger besitzend sind. Nur kann man das nicht verhindern.

Aber der Hinweis mit boost::noncopyable ist gut, oft werden die Pointer-Container nämlich zur Speicherung von Objekten mit einer Identität (z.B. polymorph und ohne Wertsemantik) verwendet. Da könnte man immer noch Clone-Funktionen einsetzen, um Kopien ohne Kopierkonstruktor zu erstellen.