class T
{
   ~T() {foo;}

   bool hallo() {delete this; return true;}
};

EDIT
Mal abgesehen davon dass nirgens spezifiziert ist, was foo ist.

EDIT2
Und natürlich muss das Objekt auch mit new erzeugt worden sein.
Hier ein wenig ausführlicher:
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15

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

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 .

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?

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.

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

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.

Er ruft delete für dich auf.

Wann?

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

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

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.