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.