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ß

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

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

X myx;
myx.Close();

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

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

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

Grüssli

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.

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.

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.

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;

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

Gruß

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

Gruß

Weil URL eine abstrakte Klasse ist die nicht instanziert werden kann (Plugins...).

Und? Kannst du ein kleines bisschen genauer werden?
Wir haben schliesslich nicht dein Wissen vom dem Konstrukt, daher muss du das schon ein wenig genauer erklären, damit wir es verstehen können. Einfach zwei Stichwörter hinzuschmeissen reicht da nicht sehr weit

Grüssli

All diese Probleme kann ich mit den Managerklassen lösen. Und da ich ja immerhin Speicher auf dem Heap zurückgebe, würde es einen Memoryleak geben, wenn man die Klasse nicht via Close() oder ähnlichem löscht.

Gruß

Und da ich ja immerhin Speicher auf dem Heap zurückgebe, würde es einen Memoryleak geben, wenn man die Klasse nicht via Close() oder ähnlichem löscht.

Es gibt da deutlich bessere möglichkeiten. Zum Beispiel im aktuellen Standard enthalten ist der auto_ptr .

std::auto_ptr<int> createSomething()
{
  return std::auto_ptr<int>(new int(3923));
}

int main()
{
  createSomething();
  return 0;
}

Dieser Code hat kein Memory Leak. auto_ptr gehört zu den sogenannten Smart Pointern. Davon gibt es einige und auch deutlich bessere als auto_ptr . Boost bietet zum Beispiel die üblichen an:
http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smart_ptr.htm

Das praktische an solchen Smart Pointern ist auch die Sicherheit bei Exceptions, da du dich dann an das RAII Konzept hälst. Nehmen wir zum Beispiel deinen Code:

URL *x = URLManager->Open("bla.de");
std::string source = x->Read();
evil_function();
x->Close();

Wenn evil_function eine Exception wirft, wird nie Close aufgerufen und du hast ein Memory Leak. Mit einem Smart Pointer wäre dies nicht passiert, da er bei seiner Zerstörung automatich den Speicher freigegeben hätte. Also zum Beispiel mit auto_ptr :

std::auto_ptr<URL> x = URLManager->Open("bla.de");
std::string source = x->Read();
evil_function();

Dies macht keine Probleme, wenn evil_function eine Exception wirft. x wird per delete trotzdem freigegeben.

Man kann auch eigene Smart Pointer Klassen schreiben, welche zusätzlichen spezialisierten Code bei der Zerstörung ausführen. Die Boost Smart Pointer können zum Beispiel bei der Erstellung eine Zerstörungsfunktion übernehmen, welche beim Löschen aufgerufen wird.

Grüssli

Eine Frage dazu habe ich aber noch. Was ist, wenn folgendes passiert?

std::auto_ptr<URL*> x = URLManager->Open("bla.de");
x->Bla();
x->Close(); // delete this

Würde der auto_ptr dann nicht versuchen, ein nicht mehr existierendes Objekt zu löschen, was in einem Crash enden würde?

Gruß

Würde der auto_ptr dann nicht versuchen, ein nicht mehr existierendes Objekt zu löschen, was in einem Crash enden würde?

Genau, daher weg mit der Close Funktion. Die ist ja nun unnötig, nicht? Und es ist übrigens std::auto_ptr<URL> (ohne Sternchen)

Grüssli