Webinar FreeAndNil

[dummzeuch]

Zitat von Rollo62:

Ich seh das jetzt nicht so dass sich hier Leute aufreiben.

Siehe englische DP.

Zitat von Neutral General:

Oh doch, das ist anscheinend sowas wie eine Religionszugehörigkeit, nur Himmel und Hölle, sonst gibt es nichts dazwischen

Schlimmer noch als Himmel und Hölle eher wie vi vs. emacs.

[jaenicke]

Zitat von Rollo62:

Oh doch, das ist anscheinend sowas wie eine Religionszugehörigkeit, nur Himmel und Hölle, sonst gibt es nichts dazwischen

Solange man seine Meinung dazu auch begründen kann...
Ich finde, dass es sowohl Anwendungsfälle gibt, an denen FreeAndNil sehr viel Sinn macht, als auch solche, bei denen es keinen / wenig Sinn macht.

[himitsu]

Nja, im Notfall kann man immer FreeAndNil machen, was nahezu nie verkehrt ist.
Während bei einem .Free das nötige Zurücksetzen der Variable eventuell fehlen könnte. (z.B. für nachfolgende if-Assigned)

Und

Delphi-Quellcode:

x.Free;
x := nil;

könnte zwar richtig sein, aber wenn es im Free knallt, dann würde das NIL nicht mehr ausgeführt.

Zu

Delphi-Quellcode:

try
  x.Free;
finally
  x := nil;
end;

hat man oft keine Lust, was man aber mit FreeAndNil (eigentlikch NilAndFree) viel "einfacher" haben würde.




Und über ein Property oder ein Function-Result zu Löschen, da geht nur Free.
Für FreeAndNil müsste man es erst in eine Variable umkopieren.
(aber nur sinnvoll, wenn sich das Objekt da drüben auch selbst deregistriert/entfernt)




Krank / unverständlich empfinde ich aber, dass man Assigned bei Property/Result nicht direkt nutzen kann.
Wieso eigentlich nicht? (ein <>NIL als Ersatz ginge zwar, aber ist schon bissl inkonsistent, wenn sonst überall anders mit Assigned)

[Sinspin]

Zitat von dummzeuch:

Schlimmer noch als Himmel und Hölle eher wie vi vs. emacs.

Wahrlich!
Es ist also eine Sünde einfach FreeAndNil zu verwenden anstatt ordentlich zu programmieren und sicherzustellen das man nicht auf Objektreferenzen zugreift deren Objekte schon freigegeben sind.
So ganz sachte verstehen ich den Salat! Verwender von FAN sind also zu faul um ordentlich zu programmieren. Das ist jedenfalls die Meinung der FAN Gegner/Verweigerer.

Das macht mich Sprachlos. FAN hat den Vorteil das ich gegenchecken kann ob das Objekt weg ist. Ich kann also Objekte freigeben, und deren Referenzzustand "freigegeben" als Schalter verwenden.
Ich sehe mich dadurch nicht als Faul, sondern als Gewissenhaft an.

[Uwe Raabe]

Zitat von Sinspin:

Verwender von FAN sind also zu faul um ordentlich zu programmieren.

Ich denke, das Argument ist eher: 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. Das FreeAndNil kann dann zu Debug-Zwecken verwendet werden, wobei man dann an anderer Stelle nicht einfach auf nil prüft und gegebenenfalls nichts macht, sondern dann eine Exception wird (die ohne Prüfung auch kommen würde). Aber das ist manchmal schon arg akademisch.

[Rollo62]

Von den ganzen Pro-Argumenten finde ich das Proaktiv-In-Der-Zukunft Argument eigentlich am Schönsten:

In einer Basis-Klasse, die mal abgeleitet werden könnte, hilft FAN im Destruktur den Zugriff auf interne Felder abzusichern,
falls die Klasse zufällig mal abgeleitet wird und dabei jemand anderes diese falsch benutzt und versucht nach Destroy drauf zuzugreifen.
So oder so ähnlich.

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.

[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.

[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.