Webinar FreeAndNil

[jaenicke]

Zitat von Rollo62:

Ist schön vorrausschauend gedacht, gefällt mir, aber ich fürchte es bleibt dabei:
Man braucht es eigentlich nicht wirklich wenn man das Klassen-Design gut ausgelegt hat.

Ich verwende FreeAndNil z.B. in Schnittstellen. Wenn ich ein Interface nach außen herausgebe, kann ich nicht prüfen, ob ein außenstehendes Stück Code die Referenzzählung korrekt durchführt. Es könnte also sein, dass jemand noch eine Referenz behält, das Objekt aber freigegeben wurde. Ohne FreeAndNil bekommt man dann eine nichtssagende Schutzverletzung.

[MyRealName]

Wenn ich eine lokale Objekt-Variable habe, dann wird die ja auf dem Stack abgelegt. Erzeuge ich die dann und gebe die wieder frei (ohne nil Zuweisung), dann bleibt der Stack mit dem nicht mehr gültigen Zeiger bestehen. Rufe ich dann die Funktion nochmal auf, könnte ich den gleichen Speicherplatz nochmal zugewiesen bekommen auf dem Stack und ich habe im ASM Code nichts gesehen, welches die lokale Variable automatisch vorinitialisiert, also rein technisch könnte sie mit einem ungültigen Pointer belegt sein. Deswegen nutze ich da immer FreeAndNil.

Oder sehe ich das falsch ? Hat sich da mittlerweile was geändert ?

[jaenicke]

Zitat von MyRealName:

Rufe ich dann die Funktion nochmal auf, könnte ich den gleichen Speicherplatz nochmal zugewiesen bekommen auf dem Stack und ich habe im ASM Code nichts gesehen, welches die lokale Variable automatisch vorinitialisiert, also rein technisch könnte sie mit einem ungültigen Pointer belegt sein.

Davor warnt der Compiler, wenn man vergisst eine Variable vor der Verwendung zu initialisieren.

[freimatz]

Ja. Außerdem ist das Problem dann nicht nur bei "Rufe ich dann die Funktion nochmal auf ..." sondern auch beim ersten mal kann die Variable dann mit falschem belegt sein.

[Uwe Raabe]

Außerdem gilt das ja nicht nur für Objekt-Instanzen sondern auch für alle anderen lokalen Variablen. Konsequenterweise müsste man die dann beim Verlassen auch alle auf 0, nil oder sonstwas setzen, damit sie bei einem möglichen nächsten Aufruf dedizierte Werte erhalten. Dann vielleicht doch besser am Anfang initialisieren.
Ubrigens: Strings, Interfaces und sonstwie gemanagete Typen werden als lokale Variablen sehr wohl initialisiert. Es macht aber dann auch nichts wenn man es selbst nochmal macht.

[Neutral General]

Zitat von MyRealName:

Oder sehe ich das falsch ? Hat sich da mittlerweile was geändert ?

Da hat sich nichts geändert, es ist normal dass der Stack voller nicht mehr genutztem Datenmüll ist, der bei Bedarf einfach Überschrieben wird.
Aber das was du beschreibst war auf der anderen Seite auch nie ein Problem. Wie Uwe schon sagte: Du musst lokale Variablen sowieso initialisieren,
wenn du keinen Datenmüll in deinen Variablen stehen haben willst. Das gilt auch schon beim aller ersten Aufruf der Funktion - Der Stack wurde vorher bereits von etlichen anderen Funktionen genutzt wodurch deine lokale (Objekt-)Variable bereits beim ersten Aufruf der Funktion mit großer Wahrscheinlichkeit einen Pointer ins Nirvana enthält, weil an der Stelle vllt. zufällig eine Schleifenvariable einer anderen Funktion liegt oder eine Rücksprungadresse oder sonst irgendwas anderes.

[Mavarik]

Zitat von Uwe Raabe:

Wenn du nicht sicher bist, ob die freigegebene Variable danach noch benutz wird, liegt ein Defekt in der Architektur vor, und den sollte man erst beheben.

Naja, genau das ist doch das Problem. Bei einem Form, das unzählige OnExit, OnChange usw. hat, wer kann genau sagen welche events alle noch getriggert werden?
Ein Resize vom Form das auf etwas zugreift oder ein Itemindex der noch belegt wird und und und!

In so einen Fall die fStringList mit FreeAndNIL zu löschen und überall Assigned vor der Verwendung zu testen, verhindert einfach eine exception ohne lange zu überlegen, was alles noch passiert.

Grüsse

[freimatz]

[QUOTE=Mavarik;1508097]

Zitat von Uwe Raabe:

Naja, genau das ist doch das Problem. Bei einem Form, das unzählige OnExit, OnChange usw. hat, wer kann genau sagen welche events alle noch getriggert werden?
Ein Resize vom Form das auf etwas zugreift oder ein Itemindex der noch belegt wird und und und!

Genau dann "liegt ein Defekt in der Architektur" vor.

[Uwe Raabe]

Zitat von Mavarik:

wer kann genau sagen welche events alle noch getriggert werden?

Ich finde, das sollte der Entwickler schon wissen. Sei es durch die Dokumentation oder, bei deren Unzulänglichkeit oder Abwesenheit, durch Analyse der Sourcen - notfalls durch ausprobieren.

[Mavarik]

Zitat von freimatz:

Genau dann "liegt ein Defekt in der Architektur" vor.

Die Aussage ich zu generell... Aber genau darum geht es ja...

Mit FreeAndNIL ist es "egal".

Zitat von Uwe Raabe:

Ich finde, das sollte der Entwickler schon wissen.

Theoretisch richtig.... Mit - sagen wir mal - 50 Komponenten auf einem Form die OnExit, OnEnter und ggf. noch mit SetFocus arbeiten... Wer kann da schon ohne debug Ausgaben sagen, was in welcher Reihenfolge kommt.

Wäre nicht das 1. mal, dass ich hier von der Reihenfolge überrascht wurde.