Wie sinnvoll ist es, Objekt Instanzen, speziell solche die viel Speicher verbrauchen, bei einer Fenster Anwendung in Form.OnDestroy oder sonstwo noch zu zerstören? Ich hab da eine Handvoll FreeAndNil() in MainForm.OnDestroy, hatte da aber eine falsche Reihenfolge was eine Access Violation zur Folge hatte. Da dachte ich mir - warum soll ich die Zeilen nicht ganz entfernen, Windows kümmert sich doch selbst darum?

Warum?

Wenn man an einer Stelle anfängt zu schludern, dann passiert es womüglich auch an anderen Stellen.

Ich schludere für gewöhnlich nicht (mehr). An anderen Stellen als OnDestroy würde ich mich ohrfeigen wenn ich vermeidbare Speicherlecks hinterlassen würde. Es ist also keine Frage der Disziplin beim Programmieren. Ich frage mich nur, ob es Sinn hat, Code zu schreiben der überhaupt keinen Effekt hat. Oder hat er einen Effekt? Nein, denke nicht, wie auch.

Ich sehe das wie Himitsu,

Du solltest immer alles was du Allokierst auch selbst wieder Frei geben. Wenn du so was nicht gerne machst, dann nimm doch Java, da ist eh alles egal.

Ich schreibe in meinen Code nach der Verwendung einer Klasse sogar immer noch Extra dsa setzen auf NIL, schaden tut das nicht. Und wenn der Compiler der Meinung ist, dass es unnötig ist, schmeißt er den Code eh wieder weg.

Zitat von Corpsman:

Ich schreibe in meinen Code nach der Verwendung einer Klasse sogar immer noch Extra dsa setzen auf NIL, schaden tut das nicht.

Doch, der Übersichtlichkeit. Jemand, der deinen Code liest, fragt sich doch: Warum macht er das?

Wenn schon, verwende FreeAndNil. Macht das Gleiche, ist auch überflüssig, aber inzwischen Usus unter Delphi-Programmierern.

Zur eigentlichen Frage: Also wenn deine SW nur(!) zum Programmende Speicher nicht freigibt (Siehe Indy), dann ist das kein Problem, hat aber einen kleinen Haken:

Wenn ich Delphi-Programme hinsichtlich Speicherlecks mit FastMM prüfe, dann bin ich erst dann zufrieden, wenn das Fehlerlog leer ist, bzw. die üblichen VCL-Macken zeigt. Da stört dann ein redundantes Freigeben einfach. Schlimm, wenn diese Struktur eine Liste mit Mio Einträgen ist (ein Cache z.B.). Das müllt mir das FastMM-Log zu. Da geb ich das doch eben frei und kann weitermachen.

Ich frage mich aber, wie Du sicherstellst, das dein Programm sonst keine Speicherlecks erzeugt? Glotzt du nur auf den Taskmanager?

Nötig ist es nicht, wie du schon selbst sagst. Wenn der Prozess beendet wird, schließt Windows alle offenen von dem Prozess belegten Ressourcen (Dateihandles, Fensterhandles, usw.) und gibt auch den gesamten Adressraum des Prozesses wieder frei. Aber ich bin der Meinung, dass es schlechter Stil ist, wenn man selbst allozierten Speicher nicht auch selbst wieder frei gibt und sei es nur der Form halber. Allerdings könnte auch eine Situation auftreten, wo das dann doch eine Rolle spielt, wenn nämlich jemand anders das Programm erweitert und sich darauf verlässt, dass du deinen Speicher auch wieder frei gibst.

Und wenn das Freigeben von Speicher zu Fehlern führt, dann hast du in deinem Code einen Fehler und den solltest du finden und beseitigen.

Hallo,

also ich hab da ein Beispiel einer dll, wenn ich die am Schluß nicht selbst free-e *g* dann bleibt die dll geladen und beim nächsten Start des Programmes, wenn nicht der Rechner neu gestartet wurde, kann die dll nicht mehr genutzt werden. Also macht Windows nicht unbedingt wirklich alles frei beim beenden.

Gruß

tom

Zitat von alzaimar:

Zitat von Corpsman:

Ich schreibe in meinen Code nach der Verwendung einer Klasse sogar immer noch Extra dsa setzen auf NIL, schaden tut das nicht.

Doch, der Übersichtlichkeit. Jemand, der deinen Code liest, fragt sich doch: Warum macht er das?

Wenn schon, verwende FreeAndNil. Macht das Gleiche, ist auch überflüssig, aber inzwischen Usus unter Delphi-Programmierern.

Ich sehe das situationsabhängig. Normalerweise rufe ich nur Free auf. Wird allerdings später nochmals auf Assigned überprüft, dann bietet sich ein FreeAndNil an. Du setzt ja sicherlich auch nicht alle anderen Variablen nach Gebrauch auf 0, Leerstring oder sonstiges, oder?