"delete this" - legal?

[theliquidwave]

Hi.
Ist folgendes, exemplarisches Beispiel nach C++ Standard legal?

class XManager
{
public:
    X *Open();
};

class X
{
public:
    ~X()
    {
        // sind hier noch alle Membervariablen, etc. valid?
    }
    void Bla()
    {
        // ...
    }
    void Close()
    {
        delete this;
    }
};

// ...
XManager *Man = new XManager;

// ...
X *y = Man->Open();
y->Bla();
y->Close(); // ab hier wäre y nicht mehr valid

Gruß

[Marc++us]

Legal ja, ob sinnvoll mag ein anderes Thema sein. Wenn Du die Klasse komplett verriegelst, daß niemand sonst irgendwie Objekte löschen kann außer mit Close, ist das zumindest in Deinem Kontext sicher.

Zur Frage im Code: im Destruktor sind alle Member noch gültig, ja.

Siehe auch http://www.c-plusplus.net/forum/viewtopic-var-t-is-228857.html

[asc]

Marc++us schrieb:

Legal ja, ob sinnvoll mag ein anderes Thema sein...

Es gibt Sonderfälle in denen es sinnvoll ist, aber es ist wirklich die Ausnahme, nicht die Regel.

lului schrieb:

nein.

Dann solltest du mal erwähnen warum nicht, wie gesagt gibt es sogar Fälle in denen dies durchaus gemacht wird (wenn auch sehr selten).

[wxSkip]

Und was ist, wenn einer ganz ahnungslos

X myx;
myx.Close();

in seinem Code schreibt und sich wundert, dass das Objekt doppelt gelöscht wird?

[volkard]

wxSkip schrieb:

Und was ist, wenn einer ganz ahnungslos

X myx;
myx.Close();

in seinem Code schreibt und sich wundert, dass das Objekt doppelt gelöscht wird?

Dann ist "Wenn Du die Klasse komplett verriegelst, daß niemand sonst irgendwie Objekte löschen kann außer mit Close" nicht erfüllt.

[wxSkip]

volkard schrieb:

wxSkip schrieb:

Und was ist, wenn einer ganz ahnungslos

X myx;
myx.Close();

in seinem Code schreibt und sich wundert, dass das Objekt doppelt gelöscht wird?

Dann ist "Wenn Du die Klasse komplett verriegelst, daß niemand sonst irgendwie Objekte löschen kann außer mit Close" nicht erfüllt.

Danke, das hatte ich überlesen.

[theliquidwave]

wxSkip schrieb:

Und was ist, wenn einer ganz ahnungslos

X myx;
myx.Close();

in seinem Code schreibt und sich wundert, dass das Objekt doppelt gelöscht wird?

Wie gesagt, das war ein Beispiel. Die Klasse ist abstrakt, kann also nicht instanziert werden. Dieser Fehler ist also ausgeschlossen.

Natürlich bleibt noch folgender Fehler:

X *y = Man->Open();
X->Close();
X->Bla(); // crash

Aber in der Dokumentation steht das dick und fett drin - und ist beabsichtigt und in diesem Fall auch sinnvoll.

Gruß und Danke

[Dravere]

Mich würde aus reiner Neugier interessieren, wieso du dies als nötig erachtest. Ich kenne verdammt wenige bis gar keine Fälle, wo sowas nötig ist. Wäre also froh, wenn ich meinen Horizont erweitern könnte

Grüssli

[volkard]

Normalerweise fängt so eine "delete this"-Klasse einen privaten Destruktor. Das verhindert für Fremde sowohl lokale und globale Objekte als auch das Zerstören mit delete.

[volkard]

Dravere schrieb:

Mich würde aus reiner Neugier interessieren, wieso du dies als nötig erachtest. Ich kenne verdammt wenige bis gar keine Fälle, wo sowas nötig ist. Wäre also froh, wenn ich meinen Horizont erweitern könnte

Man schickt dem Fenster halt ein Close und manche gehen daraufhin in den Untergrund, manche tun gar nichts, die meisten aber sind brav und verschwinden per delete this.

[Janjan]

Ist aber schlechter Stil. Wenn ein Fenster gelöscht werden soll, dann würde ich auch sagen das es gelöscht werden soll. Wenn ich ein Fenster nur schließen will, rufe ich eine Schließ-Funktion auf.

[volkard]

Ich zweifle gerade ein wenig daran, daß Du hier von Stil reden solltest, Janjan.

[Janjan]

Das ist schön für dich. Eine Funktion sollte das tun, was ihr Name bereits beschreibt. Close() sollte etwas schließen, nicht löschen.

[volkard]

Close

[Janjan]

Und? Was hat das mit dem Thema zu tun? Richtig, gar nichts.

Es ist nicht unüblich das Programm zu beenden, wenn alle Fenster geschlossen wurden. Aber sonst sollte eine Schließ-Funktion nur das tun: Schließen. Denn man könnte das Fenster ja wieder öffnen wollen.

[volkard]

Janjan schrieb:

Und? Was hat das mit dem Thema zu tun? Richtig, gar nichts.

Doch. Wenn Du ganz tief nachdenkst, kannst Du zu dem Schluß kommen, daß Close normalerweise auch bewirkt, daß das Fenster gelöscht wird. Und genau das kann man mit delete this machen. Umwege der Art, tote Fenster erst in eine Löschliste einzutragen und alle paar Sekunden die Löschliste abzuarbeiten, sind eher Umwege und sollten nicht bloß aus stilistischen Überlegungen gewählt werden, zumal man mit Zombie-Fenstern dann noch peinliche Resourcenkonflikte mit Nachfolgenden provoziert.

[Janjan]

Dem stimme ich eben schlichtweg nicht zu. Das verhindert das wiederbenutzen von Fenstern. Sinnvoller wäre dann eher eine Funktion wie closeAndDelete() - die macht dann auch das, was der Bezeichner bereits aussagt. Dazu eben eine normale close()-Funktion, die das Fenster nur schließt.

Und Zombie-Fenster und Resourcenkonflikte entstehen keineswegs dadurch. Man kann das Fenster ja nach wie vor selbst löschen, wenn es notwendig - und vor allem gewollt - ist.

wnd->close();
delete wnd;

[volkard]

Ok. Ein philosophisches Problem.

[theliquidwave]

Wenn ihr es unbedingt wissen wollt

URL *x = URLManager->Open("bla.de");
std::string source = x->Read();
x->Close();
// ist schöner als URLManager->Close(x);

Gruß

[Dravere]

volkard schrieb:

Janjan schrieb:

Und? Was hat das mit dem Thema zu tun? Richtig, gar nichts.

Doch. Wenn Du ganz tief nachdenkst, kannst Du zu dem Schluß kommen, daß Close normalerweise auch bewirkt, daß das Fenster gelöscht wird. Und genau das kann man mit delete this machen. Umwege der Art, tote Fenster erst in eine Löschliste einzutragen und alle paar Sekunden die Löschliste abzuarbeiten, sind eher Umwege und sollten nicht bloß aus stilistischen Überlegungen gewählt werden, zumal man mit Zombie-Fenstern dann noch peinliche Resourcenkonflikte mit Nachfolgenden provoziert.

Also ich schliesse oft die Fenster, frage DANACH noch Werte daraus ab und zerstöre es dann erst. Das hat den Effekt, dass der User das Gefühl hat, dass sein Interface deutlich besser reagiert. Zudem möchte ich die Möglichkeit haben, ein Fenster auf dem Stack zu erstellen, zum Beispiel für einen kurzen modalen Dialog. Genau dieses "delete this" Verhalten, welches zum Teil auch wxWidgets implementiert, finde ich katastrophal! Ich will selber die Kontrolle haben, wann ein Fenster seine Ressourcen freigibt.

Auch musst du dann ständig mit Zeigern herumhantieren. Du kannst keine Fenster als Member einer Klasse definieren, sondern kannst in der Klasse nur Zeiger auf diese halten.

Nein, gerade für Fenster ist sowas der völlig falsche Weg und ist nur unnötig einschränkend.

theliquidwave schrieb:

Wenn ihr es unbedingt wissen wollt

URL *x = URLManager->Open("bla.de");
std::string source = x->Read();
x->Close();
// ist schöner als URLManager->Close(x);

Gruß

Hä? Wieso kein auto_ptr, shared_ptr oder sonst was in der Art? Wieso keine Kopie? Wieso kein Handler? Wieso überhaupt URLManager? ... Also da stellen sich eine Menge an Fragen

Grüssli