Free oder FreeAndNil=

[Pilloker]

Hallo,

ich weiß nicht, wann ich INSTANZ.Free aufrufen muss, und wann FreeAndNil(INSTANZ).
Wer kann es mir erklären?

Danke.

[mkinzler]

Object.Free() gibt das Objekt frei. Die Referenzvariable verweist aber immer noch auf den Speicher des Objekts. FreeAndNil() setzt diese zusätzlich aug Nil

[QuickAndDirty]

Wobei zu berücksichtigen ist das FREEANDNIL
Probleme machen kann wenn man die von Delphi automatisch erstellten Formular Variablen
nutzte um in einem Close oder Destroy oder Hide Event des Formulars auf das Formular zuzugreifen.
Also anstelle von Self.

[Aphton]

Im Großen und Ganzen - dann, wenn du das Objekt auf <> NIL checkst. Also falls ein paar deiner Funktionen solche checks haben, wirds Fehler geben, falls die Instanz schon zerstört wurde.

Delphi-Quellcode:

var
  X: TControl;
begin
  X         := TControl.Create( Self );
  X.Parent  := Self;
  Randomize;
  case Random(2) of
    0: X.Free;
  else
    FreeAndNil( X );
  end;
  if Assigned( X ) then // #1#
    X.Free;

#1#: Falsl bei der zuvorigen case Abfrage 0 das Ergebnis war, dann wurde das Objekt nur zerstört, die Variable X enthält jedoch noch die Adresse. Somit schlägt Assigned fehl, da es auf NIL prüft ... wohingegen FreeAndNil wie schon gesagt wurde, die Variable nach dem Zerstören auch auch NIL setzt.

MfG

[mleyen]

FreeAndNil() sollte immer dann aufgerufen werden, wenn das übergebene Objekt weiterhin benutz wird.
Dadurch kann man prüfen, ob das Objekt noch existiert (<> nil) oder schon freigegeben wurde. (= nil)

Wenn du z.B. im Destruktor TObject.Free() aufrufst, macht das (meists) nichts aus, da das Objekt nicht weiter benutzt wird.

[Pilloker]

Also kann man sagen, dass es generell in Ordnung ist, wenn man stets FreeAndNil aufruft (den Punkt von
QuickAndDirty mal ausgenommen)?

[mleyen]

Ja, kann man sagen.
Der einzigste Unterschied der mir gerade einfällt:
Die Objekt-Referenz muss immer schreibbar sein. (Übergebe als var-Parameter)
Z.B. bei property-Objekten ohne setter dürfte das dann nicht funktionieren.

Edit #1:
Und es muss natürlich die Unit SysUtils mit eingebunden sein, was nicht immer gewünscht ist.

[hoika]

Hallo,

nun ja, das NIL-Setzen kostet "etwas" Zeit.

Was man sagen kann, dass dort wo Free aufgerufen wird,
ein FreeAndNIL auch OK ist.

Die Erklärungen waren doch einleuchtend, oder ?

Benutze ich eine Variable mehrfach, gebe Sie dabei immer wieder zwischendurch frei,
kann ich durch Nutzung von FreeAndNIL zwischendurch prüfen,
ob sie aktuell in Benutzung ist, oder nicht.

1. Code.-Bsp.

Delphi-Quellcode:

object.Free;
if Assigned(object) -> liefert Müll

2. Code.-Bsp.

Delphi-Quellcode:

object.Free;
FreeAndNIL(object);
if Assigned(object) -> liefert immer False (weil object NIL ist)

#Update:#
Das ist natürlich getrennt zu betrachten !



Heiko

[himitsu]

Zitat:

Ja, kann man sagen.

joar

Zitat:

Der einzigste Unterschied der mir gerade einfällt:
Die Objekt-Referenz muss immer schreibbar sein. (Übergebe als var-Parameter)
Z.B. bei property-Objekten ohne setter dürfte das dann nicht funktionieren.

nja, es darf nur nicht CONST sein, aber normaler Weise werden Objekt-Parameter nicht als CONST definiert, also geht es da

abgesehn von den Propertys, aber da gibt man ja fast nie das Objekt via Free frei, sondern verwendet andere Wege

[xZise]

Zitat:

Zitat von hoika

[...]
kann ich durch Nutzung von FreeAndNIL zwischendurch prüfen,
ob sie aktuell in Benutzung ist, oder nicht.

Delphi-Quellcode:

object.Free;
if Assigned(object) -> liefert Müll

FreeAndNIL(object);
if Assigned(object) -> liefert immer False (weil object NIL ist)

Sicher? Ich würde sagen, "FreeAndNil" nach "Free" wird auch einen Fehler werden :P

MfG
xZise

[mkinzler]

Zitat:

Sicher? Ich würde sagen, "FreeAndNil" nach "Free" wird auch einen Fehler werden Razz

Nein, den FreeAndNil() überprüft vorher

[DeddyH]

Ja, das prüft auf Assigned(), was in diesem Fall aber das falsche Ergebnis liefert, also knallt es.

[Hawkeye219]

Hallo,

Fabian bezog sich wohl auf den von Heiko geposteten Code. Man muss die beiden Codestücke in dessen Beispiel voneinander losgelöst sehen.

Gruß Hawkeye

[taaktaak]

Zitat:

FreeAndNil() überprüft vorher

Offenbar aber nicht in allen Versionen der "SysUtils"
- in meiner (Delphi 7) Version kann ich keine Prüfung entdecken :(

[himitsu]

Jaaaa, also wenn man den Code genauso nimmt, wie er dort steht, dann knallt es natürlich :roll:

ich glaub es war auch mehr so gemeint :zwinker:

Delphi-Quellcode:

object.Free;
if Assigned(object) -> liefert Müll

Delphi-Quellcode:

FreeAndNIL(object);
if Assigned(object) -> liefert immer False (weil object NIL ist)

[edit]
genau @Hawkeye219

@taaktaak:
doch doch

Delphi-Quellcode:

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

[Muetze1]

Zitat:

Zitat von taaktaak

Zitat:

FreeAndNil() überprüft vorher

Offenbar aber nicht in allen Versionen der "SysUtils"
- in meiner (Delphi 7) Version kann ich keine Prüfung entdecken :(

Falsch formuliert: .Free prüft vorher und da FreeAndNil() intern .Free aufruft, hat es auch diese Prüfung.

@QuickAndDirty: Dein Argument ist hinfällig, da alles was du beschreibst auf unsaubere Programmierung hindeutet und genau da liegt das Problem und nicht bei FreeAndNil()

[taaktaak]

Asche auf mein Haupt
- natürlich :pale:

[Dezipaitor]

Interessant:
http://blog.eurekalog.com/?p=135