3. "delete this" - legal?

"delete this" - legal?

  • W

    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.

    0
  • T

    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

    0
  • Administrator

    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

    0
  • V

    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.

    0
  • V

    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.

    0
  • J

    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.

    0
  • V

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

    0
  • J

    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.

    0
  • V

    Close

    0
  • J

    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.

    0
  • V

    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.

    0
  • J

    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;
    0
  • V

    Ok. Ein philosophisches Problem.

    0
  • T

    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ß

    0
  • Administrator

    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

    0
  • T

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

    Gruß

    0
  • Administrator

    theliquidwave schrieb:

    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

    0
  • T

    Also...
    ...das ganze kommt daher, dass ich verschiedene Managerklassen habe (so mein bisheriges Konzept). Jede Managerklasse wird vom Programm instanziert und via GetProcAddress / dlsym wird dann später der Pointer zu diesen Klassen geholt (jede Instanz einer Managerklasse gibt es nur einmal im Programm, alle Plugins greifen auf diese zu). Da ich vermeiden möchte, dass ich ewig den Sourcecode mitgeben muss, habe ich alle Klassen, die man verwenden kann, abstrakt gemacht. Man kann diese also nur via Managerklasse instanzieren (lassen). So brauche ich den Sourcecode zu einer Headerdatei nicht immer preisgeben / die Pluginautoren müssen nicht ewig den ganzen Sourecode neukompilieren. Es wäre auch "dumm" wenn jeder Pluginautor den Sourcecode ändert um andere Ergebnisse zu erzielen - die Konsistenz würde einfach verloren gehen.

    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ß

    0
  • Administrator

    Die Managerklasse habe ich nicht zu 100% verstanden, aber da scheint wohl einen tieferen Sinn dahinter zu stecken. Wo ich allerdings mühe habe, ist bei diesem Satz:

    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

    0
  • T

    Wie Genial ist das denn? Ich kannte die Teile gar nicht. Für meinen Fall scheinen die echt sinnvoll zu sein. Danke für den Tipp 👍

    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ß

    0
Anmelden zum Antworten