Objekt selbst löschen

[gelbfinger]

Man kann ein Objekt selbst löschen, wenn man "delete this" ausführt. Leider ziegt dann dieser this-Zeiger immer noch auf dieses irreguläre Objekt. Wie kann man diesen this-Zeiger im Destruktor so verbiegen, dass er z.B. auf 0 zeigt? So, dass ein Aufruf des Objekts einen Programmfehler/-abbruch verursacht?

[evilissimo]

Das geht nicht, und das ist auch gut so. Wenn du delete this aufrufst wird der Destruktor aufgerufen.
Wenn du das Objekt dann weiterverwendest dann machst du was in deinem Programm falsch.
Wenn du dafür sorgen willst, dass das Programm endet dann benutze exit(0) oder schmeiß ne exception von der du weißt das Sie nicht gefangen wird. Was weiß ich...

[gelbfinger]

Mir geht es um die Entwicklung eines neuen Singleton-Typs. Ich möchte keinesfalls, dass das Programm ins Bodenlose abstürzt. Das Objekt darf aber nicht weiterverwendbar sein. Daher möchte ich es möglichst sicher "entsorgen", "blockieren" ... Es darf keine Methode des Objektes nach Aufruf des Destruktors mehr ausführbar sein. Wenn das klappen würde, wäre toll. Idee?

[evilissimo]

Setz ein Flag im Singleton ob das Objekt noch lebt oder nicht und gib, wenn das Objekt nicht mehr existiert einen Nullzeiger zurück.

BR
Vinzenz

[gelbfinger]

Setz ein Flag im Singleton ob das Objekt noch lebt oder nicht und gib, wenn das Objekt nicht mehr existiert einen Nullzeiger zurück.

Das habe ich auch schon überlegt. Aber es soll auch wie folgt laufen:

MySingleton SingleObj1;
SingleObj1.show(); //Infos
SingleObj1.doSomeThing(); //Methode

MySingleton SingleObj2;
//RefCount im Konstruktor,Copy-Konstruktor bzw. Op= löst "delete this" aus
//Destruktor soll nun geordnet dafür sorgen, dass folgendes nicht mehr geht:
SingleObj2.show(); //Bumm!
SingleObj2.doSomeThing(); //Bumm!

Wie soll das mit einem Null-Zeiger verhindert werden?
Daher wollte ich ja "this" auf Null setzen, das blöde Ding ist aber kein Lvalue.

[LordJaxom]

Was ist denn das für ein Singleton?!

Meine Singletons lassen sich normalerweise garnicht instanziieren

[gelbfinger]

ganz einfach:

Singleton 1:
ctor erhöht refCount von 0 auf 1.

Singleton 2:
ctor/copycon stellt fest, dass refCount == 1 und löst sofort "delete this" aus. Jetzt muss die "Todgeburt" des zweiten Objekts nur möglichst vollständig gelingen.

Wenn das sinnvoll gelingen würde, bräuchte man nicht diesen hässlichen static Mist.

[Gast]

Irgendwie kann ich mir nicht vorstellen, dass diese Konstruktion in irgendeinem Fall was nützt. Schildere doch mal, was du ursprünglich damit bezwecken willst.

[David_pb]

Ich denke er will einfach verhindern das eine zweite Instanz seines Singletons erzeugt werden kann. Dazu das Objekt zwingen sich selbst zu löschen ist allerdings kein guter Gedanke. Der "hässliche static Mist" ist garnicht so schlecht wie man denken sollte...
Es ist irgendwie nicht besonders sinnvoll ein halb initialisiertes Objekt zu löschen... Nunja.

grüße

[CStoll]

Ich glaube, du gehst von der falschen Seite an dein Problem heran - statt überschüssige Objekte zu vernichten, kannst du gleich ihre Entstehung abblocken (alle Konstruktoren und Zuweisung privat setzen und Zugriff über eine statische Funktion, die immer das EINZIGE Singleton zurückgibt).

[Javaner]

gelbfinger schrieb:

Ich möchte keinesfalls, dass das Programm ins Bodenlose abstürzt. Das Objekt darf aber nicht weiterverwendbar sein.

Wenn du es gelöscht hast kann es auch gar nicht weiterverwendet werden.

Du kannst höchstens den Speicher, den es mal belegt hat, auslesen
und manipulieren.

Und wenn das passiert ist halt dein Programm malle.

[Erhard Henkes]

Schau mal bei Andrei Alexandrescu, Modern C++ Design, Kapitel 6 vorbei. Da findest Du die wesentlichen Policies.