Nur free oder FreeandNil

[NicoDE]

Zitat:

Zitat von Luckie

Oder
[...]

Da fehlte ein var und der Zeiger sollte vor dem Freigeben gesetzt werden (trotzdem wäre bei SMP-Systemen ein Lock nicht überflüssig...)

Delphi-Quellcode:

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

[Christian Seehase]

Moin Luckie,

wenn, dann aber

Code:

procedure D4FreeAndNil([color=red][b]var[/b][/color] Obj: TObject); 
begin 
  Obj.Free; 
  Obj := nil; 
end;

ohne das var davor wird der Wert von Obj nicht auf nil gesetzt. ;-)

[Luckie]

Zitat:

Zitat von NicoDE

Da fehlte ein var und der Zeiger sollte vor dem Freigeben gesetzt werden (trotzdem wäre bei SMP-Systemen ein Lock nicht überflüssig...)

Delphi-Quellcode:

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

Überredet. ;)

[Christian Seehase]

Moin Nico,

Zitat:

Zitat von NicoDE

...und der Zeiger sollte vor dem Freigeben gesetzt werden...

OK, aber warum?

[NicoDE]

Zitat:

Zitat von Christian Seehase

OK, aber warum?

Eigentlich gibt es - was SysUtils.FreeAndNil angeht - keinen echten Grund dafür, da Temp ohnehin nicht validiert wird (deswegen 'sollte'...).
Dem Benutzer muss klar sein, dass eine doppelte Freigabe nicht möglich ist.

Eine eigene Funktion im Stile von...

Delphi-Quellcode:

procedure MyFreeAndNil(var Obj);
var
  Temp: TObject;
begin
{$IFDEF WIN32}
  Temp := TObject(InterlockedExchange(Integer(Obj), Integer(nil)));
  if Temp <> nil then
    Temp.Free;
{$ELSE}
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  if Temp <> nil then
    Temp.Free;
{$ENDIF}
end;

...kann in MT-Scenarien durchaus hilfreich sein.

Ist aber alles eine Frage des Kontextes in dem man die Funktion verwenden möchte. SysUtils.FreeAndNil hat den Vorteil, dass man doppelte Freigaben schneller bemerkt. Die oben skizzierte Version hat ihre Vorteile bei der einfacheren Handhabung von Objekten, welche von mehreren Threads verwendet werden (und auch nur dann, wenn man selbst kein Locking für die Freigabe implementiert hat, bzw. implementieren will - insofern bleibt die Nützlichkeit von MyFreeAndNil fragwürdig...).


Gruss Nico

[Robert Marquardt]

FreeAndNil ist wirklich eine interessante Funktion.
Luckie zeigt die Borland-Implementation. Die kann lustige Nebenwirkungen haben, da innerhalb des Free auf die bereits zu nil gesetzte Variable gegriffen werden kann. In dem Fall bleibt nur die Seehase-Methode.
Generell sollte man FreeAndNil immer anwenden, ausser an performance-relevanten Stellen. Das ist aber ausgesprochen selten.

Bei der JVCL habe ich z. B. mal die finalization-Sections entsprechend aufgearbeitet und danach stuerzte Delphi nicht mehr ab wenn man alle Pakete neu uebersetzte.

[Nicodius]

ich denke ein normales free tuts in den meisten fällen(*mirwiederfeindemach* ;) )...

[Robert Marquardt]

Bei kleinen Projekten ja, aber bei grossen mit mehreren Programmierern ist FreeAndNil sehr hilfreich.

[Phoenix]

Also wenn ich Objekte nur innerhalb von Funktionen verwende, nehme ich free, wenn ich das Objekt später in der Funktion nicht mehr verwende (will heissen im finally - Block am Ende, wo die Funktion eh endet).

EInfach aus den Grund: Nach dem Ende der Funktion gibt es die Variablen eh nicht mehr. Dann brauch ich sie nicht auf nil setzen wenn sie eh weggeworfen wird.

Anders ist das bei Member-Variablen meiner Objekte. Diese gebe ich immer mit FreeAndNil frei (ausser im Destruktor, danach gibts das Objekt ja auch nicht mehr).

Will heissen: Genau dann, wenn ich nach der Freigabe gar nicht mehr auf die Referenz zugreifen kann, verwende ich Free, in allen anderen Fällen FreeAndNil.

[Helmi]

hallo,

es ist interessant, was eine kleine Frage auslösen kann :-D

aber ich dank euch trotzdem für die ganzen Kommentare...

:-D :-D

mfg
Helmi

:thuimb: