Unterschied zwischen FreeAndNil(Objekt) und Objekt.Free

[mkinzler]

Zitat:

Wie meinst Du das? Wird das .Free einer lokales Variable am Ende der Prozedur automatisch aufgerufen oder wird nur der Zeiger auf nil gesetzt?

.Free ruft .Destroy auf, gibt also den Speicher frei ohne die Referenz auf Nil zu setzen

[Khabarakh]

Zitat von pertzschc:

Zitat von jbg:

Für lokale Variablen ist FreeAndNil z.B nicht notwendig, wenn zu einem späteren Zeitpunkt in der Funktion nicht mehr auf diese Variable zugegriffen wird.

Wie meinst Du das? Wird das .Free einer lokales Variable am Ende der Prozedur automatisch aufgerufen oder wird nur der Zeiger auf nil gesetzt?

Tritt eine Variable aus dem Scope, geht ihr Inhalt verloren. also ist es egal, ob der Pointer nun noch auf das (hoffentlich) freigegebene Objekt zeigt oder mit FreeAndNil auf nil gesetzt wurde.

Zitat von jbg:

Zitat von Khabarakh:

Man könnte höchstens sagen, dass bei einem Aufruf von FreeAndNil ein weiteres Free(AndNil) nicht fehlschlagen wird.

Sofern die Variable nicht aus ihrem Sichtbarkeitsbereich (scope) tritt und somit nicht mehr erreichbar ist.

Ich weiß, was du meinst, aber auf eine aus dem Scope getretene Variable lässt sich schlecht eine Prozedur anwenden .

[Hansa]

Zitat von jbg:

..Man kann es nämlich mit FreeAndNil auch übertreiben...

Das könnte man wirklich unterschreiben. Das Speichermanagement von Delphi ist nicht schlecht und macht vieles automatisch. Die Frage hat sich hier aber auch gestellt. Es gibt Destroy, Free, FreeAndNil. Genau ! Wo liegt jetzt der Unterschied ? Selbst mit Borland-Unterstützung war das nicht genau zu klären, was man nun am besten wo und wann verwenden soll. Bei allen drei Alternativen gab es hier und da einen Fehler. Je nach Konstellation.

Ist schon etwas länger her, aber ich glaube das auf NIL setzen reichte nicht aus, sofern darauf geprüft wird und ein zu entfernendes TObject ist nicht da. Bevor mir einen einen Strick daraus dreht : das nächste ist ohne Gewähr. Ist das TObject in keinster Weise initialisiert, dann kommen vermutlich Fehler. Folgende Konstruktion lief bisher ohne jeden Fehler :

Delphi-Quellcode:

if Objekt <> nil then begin
  Objekt.Free;
  Objekt := nil;
end;

Das FreeAndNil könnte da vielleicht eine Zeile sparen aber nicht ohne die Abfrage <> nil ! Damit wird aber jetzt nicht rumgespielt, denn es gilt : "Never change a running system".

[mkinzler]

Die Abfrage auf Nil macht IMHO FreeAndNil

[Muetze1]

FreeAndNil() überprüft nicht, aber Free macht dies. Und Free wird aufgerufen. Somit lässt sich's Hansa's abschliessendes Codestück durch einen einzigen FreeAndNil() Aufruf ersetzen, der gleiches macht.

FreeAndNil():

Delphi-Quellcode:

procedure FreeAndNil(var Obj);
var
  P: TObject;
begin
  P := TObject(Obj);
  TObject(Obj) := nil;  // clear the reference before destroying the object
  P.Free;
end;

Free Methode:

Delphi-Quellcode:

procedure TObject.Free;
asm
        TEST    EAX,EAX      // If not Assigned Then
        JE      @@exit       //   goto exit

        MOV     ECX,[EAX]    // get virtual methode table
        MOV     DL,1    
        CALL    dword ptr [ECX].vmtDestroy   // call actual Destroy methode implementation for the instance
@@exit:
end;

Einer von den Geeks hier im Forum könnte uns mal aufklären, warum in DL unbedingt eine 1 stehen muss beim Aufruf von Destroy

[Hansa]

Zitat von mkinzler:

Die Abfrage auf Nil macht IMHO FreeAndNil

Ne, macht sie nicht :

Delphi-Quellcode:

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

Um Zeile 16275 in Sysutils.pas (D7) Eine Abfrage auf NIL ist da nicht zu sehen. Warum auch immer, aber nur der vorher gepostete Code hat sich als wasserdicht herausgestellt.

[Muetze1]

Zitat von Hansa:

Um Zeile 16275 in Sysutils.pas (D7) Eine Abfrage auf NIL ist da nicht zu sehen. Warum auch immer, aber nur der vorher gepostete Code hat sich als wasserdicht herausgestellt.

Siehe mein Post. FreeAndNil() macht keine Abfrage sondern ruft Free auf. Und Free macht diese Abfrage.

[Hansa]

Mütze, das ist fies. Erst halb schreiben und dann nachträglich editieren, während ich die relevante Stelle im Source suche.

[Muetze1]

Zitat von Hansa:

Mütze, das ist fies. Erst halb schreiben und dann nachträglich editieren, während ich die relevante Stelle im Source suche.

Sorry, aber ich hatte erstmal noch überlegt, ob ich den Teil poste, da es ja Borland gehört. Aber ich habe mich erst nachträglich dafür entschieden.

Hinweis: Die Kommentare vom Assemblercode sind von mir...

[Hawkeye219]

Hier ist noch etwas von Borland:

Zitat von Delphi-Sprachreferenz, Abschnitt 'Ablaufsteuerung':

Konstruktoren und Destruktoren verwenden dieselben Aufrufkonventionen wie die anderen Methoden. Es wird jedoch ein zusätzlicher Boolescher Flag-Parameter übergeben, der den Kontext des Konstruktor- oder Destruktoraufrufs anzeigt.

Der Wert False im Flag-Parameter eines Konstruktoraufrufs zeigt an, dass der Konstruktor über ein Instanzobjekt oder mit dem Schlüsselwort inherited aufgerufen wurde. In diesem Fall verhält sich der Konstruktor wie eine normale Methode. Der Wert True im Flag-Parameter eines Konstruktoraufrufs zeigt an, dass der Konstruktor über eine Klassenreferenz aufgerufen wurde. In diesem Fall erzeugt der Konstruktor eine Instanz der mit Self referenzierten Klasse und gibt in EAX eine Referenz auf das neu erzeugte Objekt zurück.

Der Wert False im Flag-Parameter eines Destruktoraufrufs zeigt an, dass der Destruktor mit dem Schlüsselwort inherited aufgerufen wurde. In diesem Fall verhält sich der Destruktor wie eine normale Methode. Der Wert True im Flag-Parameter eines Destruktoraufrufs zeigt an, dass der Destruktor über ein Instanzobjekt aufgerufen wurde. In diesem Fall gibt der Destruktor die mit Self bezeichnete Instanz frei, bevor er beendet wird.

Der Flag-Parameter verhält sich so, als ob er vor allen anderen Parametern deklariert worden wäre. Bei der Konvention register wird er im Register DL übergeben. Bei pascal erfolgt die Übergabe vor allen anderen Parametern. Bei den Konventionen cdecl, stdcall und safecall wird er direkt vor dem Parameter Self übergeben.

Der Wert von DL muss deshalb vor der Beendigung des Programms wiederhergestellt werden, damit BeforeDestruction oder AfterConstruction ordnungsgemäß aufgerufen werden kann.

Gruß Hawkeye