Aufräumarbeiten bei Anwendungsende

[Der schöne Günther]

Danke für die Antworten bislang!

Zitat von Uwe Raabe:

Beim Destroy einer Klasse weiß ich in der Regel nicht, ob lediglich die Instanz freigegeben wird oder das Programm beendet. Ebensowenig weiß ich, was um mich herum gerade passiert.

Absolut, das kann man nicht wissen, das ein Destruktor in der Regel alles aufräumen sollte was man aufgebaut hast stellt sicher niemand in Frage ��

Zitat von freimatz:

Nu ja, da geht es um DLLs

In der Überschrift schon, aber das lässt sich auch übertragen. So zum Beispiel in dem anderen Artikel.

Zitat von Lemmy:

Der nächste Entwickler nach Dir räumt auf (schließt z.B. irgend welche Handles) und ist am Ende irritiert, dass sein Code nicht ausgeführt wird, weil ein Schlaumeier vor ihm irgendwo ein ExitProcess eingebaut hat.

Ja, aber wenn die Anwendung endet, dann endet sie halt. Sein Coe würde auch nicht ausgeführt bei Stromausfall oder wenn die Anwendung abstürzt. Das Betriebssystem kümmert sich nach Prozess-Ende schon selbst darum dass Dateien, Handles usw. ordentlich geschlossen werden.


In einer anderen Anwendung tun wir genau das: WENN Sie endet:

1. Stelle Sicher dass alle kritischen Dinge (Ausgänge, Motoren, ...) im sicheren Zustand sind
2. Schreibe Einstellungen auf die Platte
3. Schreibe in Log-Datei dass die Anwendung nun zu Ende ist
4. Andwendung endet

Dieser Teil muss natürlich gemacht werden und ist ganz spezifisch für die einzelne Anwendung. Ich fand das ziemlich sinnvoll.


Im konkreten Fall weiß ich auch was so lange braucht. Es wäre ein irrsinniger Aufwand das so umzubauen dass es sich jederzeit abbrechen ließe. Und es macht, wie der gute Raymond sagt, auch keine Sinn. Niemand interessiert sich mehr für das Ergebnis.

[himitsu]

Es gibt guten einen Grund, um immer aufzuräumen.

Wenn du am Ende noch einen Speicherlecktest ausführen willst.
Das geht ja nur, wenn auch vorher alles aufgeräumt wurde, denn nur dann siehst du auch, was davon wirklich die Lecks sind. (alles, was dann noch da ist, und was nicht "absichtlich" unfreigegeben blieb System.RegisterExpectedMemoryLeak)

[Zacherl]

Halte es auch für guten Stil am Ende aufzuräumen. In der Regel passiert das doch eh "automatisch", wenn die letzte Klasse freigegeben wurde. Sollte es zumindest, wenn die Klassen selbst im Destructor für Ordnung sorgen.

[Der schöne Günther]

Vielleicht beeindruckt mich auch nur Raymond Chens anschauliches Beispiel so sehr. Ich meine, er hat ja nicht Unrecht. Welchen Sinn macht es, akribisch jedes Byte freizugeben wenn die Anwendung sowieso nicht mehr gebraucht wird?

Speicherleck-Tests sind ein guter Grund, aber das versuche ich mittlerweile eher über die Unit-Tests zu machen.


Dass die Anwendung am Schluss freundlich alle Verbindungen zumacht und Tschüss sagt, da hat der Benutzer auch nichts von (außer Wartezeit). Hmm…


Ich hätte erwartet mehr Zuspruch zu bekommen 🤔

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich hätte erwartet mehr Zuspruch zu bekommen 🤔

Ich vermute mal, daß das Problem mit der Wartezeit vielleicht nicht so weit verbreitet ist.

[Whookie]

Ich kann mich dem nur Anschließen, mit übermäßiger Wartezeit beim Programmende hatte ich nur selten zu kämpfen. Mit Programmen die am Ende Daten leaken habe ich aber noch nie positive Erfahrungen gemacht (allein deshalb ist meiner Meinung nach, beim Programmende alles korrekt freizugeben).

Ob sich bei einem Stromausfall oder Crash das Betriebssystem nun wirklich um alles kümmert spielt daher für mich kaum eine Rolle und aus meiner Erfahrung würde ich sage: "Mal so mal so"

[sh17]

Vielleicht lässt sich der Speicherbereich, der hier anscheinend so viel Zeit in Anspruch nimmt, um bereinigt zu werden, anders organisieren??? Da müsste man nur wissen worum es geht?

[freimatz]

Zitat von Der schöne Günther:

Zitat von Uwe Raabe:

Beim Destroy einer Klasse weiß ich in der Regel nicht, ob lediglich die Instanz freigegeben wird oder das Programm beendet. Ebensowenig weiß ich, was um mich herum gerade passiert.

Absolut, das kann man nicht wissen, das ein Destruktor in der Regel alles aufräumen sollte was man aufgebaut hast stellt sicher niemand in Frage ��

Nicht? Genau so habe ich Raymond aber verstanden.

Zitat von Der schöne Günther:

Vielleicht beeindruckt mich auch nur Raymond Chens anschauliches Beispiel so sehr. Ich meine, er hat ja nicht Unrecht. Welchen Sinn macht es, akribisch jedes Byte freizugeben wenn die Anwendung sowieso nicht mehr gebraucht wird?

Ja, es macht keinen Sinn alles freizugeben, wenn die Anwendung sowieso nicht mehr gebraucht wird. Aber: eben nur wenn. Wie Uwe schon schrieb, kann die Klassen das nicht (ohne weiteres) wissen ob das "wenn" nun eintritt.
Oder willst Du ein globales Flag Shutdown: Boolean einführen und in jedem destructor prüfen ob das gesetzt ist?

[himitsu]

Zitat von freimatz:

Oder willst Du ein globales Flag Shutdown: Boolean einführen und in jedem destructor prüfen ob das gesetzt ist?

Gibt es schon: Application.Terminated Aber so direkt in Komponenten sollte man es dann doch nicht verwenden, denn
* in einer Service-Anwendung kommt "Application" nicht aus der Unit Forms, sondern aus SvcMgr
* im FMX ist es FMX.Forms statt VCL.Forms
* In einem Thread wäre es Self.Terminated , falls der Thread in der RTL gekapselt wäre,
und außerhalb der Threadklasse könnte man auf die Idee kommen TThread.CurrentThread.Terminated zu nehmen, was aber nicht funktioniert, da CurrentThread eine "eigene" Klasseninstanz nutzt und der Terminated-Flag nicht durchgereicht wird.
* ...
und für eine Komponente/Unit ist beim Kompilieren aber nicht ersichtlich, wo sie verwendet wird.