Warum FreeAndNil so umständlich?

[Cöster]

Hi!

Bei der Implementierung von FreeAndNil hätte ich eigentlich erwartet:

Delphi-Quellcode:

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

Allerdings ist es etwas umständlicher implementiert:

Delphi-Quellcode:

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

Könnt ihr mir sagen, warum?

[Gruber_Hans_12345]

ohne eine ahnung zu haben, würde ich mal drauf tippen : damit der übergebene Pointer auf nil gesetzt wirde, selbst wenn im Destroy des Objektes eine Exception auftritt, und damit das FreeAndNil unterbrochen wird

[sakura]

Zitat:

Zitat von Gruber_Hans_12345

ohne eine ahnung zu haben, würde ich mal drauf tippen : damit der übergebene Pointer auf nil gesetzt wirde, selbst wenn im Destroy des Objektes eine Exception auftritt, und damit das FreeAndNil unterbrochen wird

100% korrekt!

...:cat:...

[MStoll]

Hi

nur ma ne Frage am Rande dazu. Wäre es langsamer, es stattdessen mit nem try..finally-Konstrukt zu versuchen? Find ich irgendwie eleganter...

Gruß
Michael

[omata]

Wieso try-finally :gruebel: Meinst du vielleicht try-except :?:

Verwirrte Grüsse
Thorsten

[Kedariodakon]

Ich denke nicht =p
Das ist so schon die schnellste Variante, würd ich behaupten..

Bye Christian

[himitsu]

Delphi-Quellcode:

procedure FreeAndNil(var Obj); 
begin 
  try
    Obj.Free;
  finally
    Pointer(Obj) := nil; 
  end;
end;

und ja, try-finaly wäre für diese Prozedur angebracht.
try-except würde die Exception abfangen und genau dieses soll nicht in dier Prozedur erfolgen.


was try-finally in etwa machen würde (als grobes Schema):

Delphi-Quellcode:

procedure FreeAndNil(var Obj); 
begin 
  ExceptionHandler.Installieren;  // if Exception then goto doExcept;
  Obj.Free;
  goto doFinally;

  doExcept:
  ExceptionHandler.StackWiederherstellen;
  goto doFinally;

  doFinally:
  ExceptionHandler.Freigeben;
  Pointer(Obj) := nil; 
end;

[Luckie]

Warum sollte Free eine Exception auslösen? Dies könnte nur passieren, wenn das Objekt nil ist, aber das überprüft Free vorher.

[himitsu]

Free ruft Destroy auf und darin kann ja wohl Unterumständen was passieren.

[Kedariodakon]

Wenn im Destructor eine Exception passiert, passiert die, auch bei free...

Und dann wär die Variable nicht nil..
so wird sie erst auf nil gesetzt und dann das eigendliche Object zerstört...


Bye Christian