Eine Variable mit einem Objekt während der Lebenszeit dieser Variable.
Free reicht, wenn nach dem Free nicht mehr auf die Variable zugegriffen wird.
Gibt es aber mehrere Stellen wo erstellt oder freigegeben wird, dann muß die Variable auch auf nil gesetzt werden.
Eine Variable wo während der Laufzeit mehrere Objekte drin gespeichert/verlinkt sind und zwischendurch auch mal nichts drin stehen kann, dann ebenfalls nil setzen.
Ob nun FreeAndNil oder Free plus :=nil das sei jedem selbst überlassen.
Immer FreeAndNil, falls ich mal irgendwo scheiße bau und nicht mehr weiß was ich wo mache =
schwachsinn sinnlos, siehe Nicks Blog.
Aber hier *muss* nil gesetzt werden,
am Besten via FreeAndNil, falls es im Free/Destroy knallen kann, sonst knallt es bestimmt nochmal beim letzten Free und schrottet mir die originale Fehlermeldung/Fehlerposition.
Delphi-Quellcode:
o := TMyObj.Create;
try
...
FreeAndNil(o);
...
finally
o.Free; // hier ist intern ein IF ASSIGNED(SELF) drin
end;
Delphi-Quellcode:
o := nil; // genauso, wie das hier nicht vergessen werden darf
try
...
o := TMyObj.Create;
...
FreeAndNil(o);
...
finally
o.Free; // hier ist intern ein IF ASSIGNED(SELF) drin
end;
@DasWolf: Jupp, also wie gesagt, wird nach dem Free nochmal irgendwie auf den Inhalt zugegriffen, dann NIL nicht vergessen zu setzen.
Und auf die grauenhaften Besonderheiten im NextGen will jetzt niemand eingehen. (ich sag nur "Free" macht garnichts und Objekte werden nicht da freigegeben wo und wann ich es will/erwarte)
PS: Wäre der Compiler intelligent genug und täte beim .Free oder .Destroy den Status der Variable zurück auf "nicht initilisiert" setzen,
wann gäbe es hier
Delphi-Quellcode:
x.Free;
if Assigned(X) then
// oder
x.Free;
x.irgendwas;
eine der bekannten Warnungen, beim nachfolgenden Zugriff.
(Variable nicht initialisiert)