Probleme mit TObject.Free

[Keldorn]

Hallo

wieso weißt du nicht, ob das Object nicht schon freigegeben wurde? Wenn du so vorgehst, wie in deinem Bsp, kann doch gar nix passieren. Ich verwende eigentlich nie FreeAndNil und hab trotzdem keine Probleme mit der doppelten Freigabe.

Mfg Frank

[LoRd-MuldeR]

So schön einfach wie im Beispiel sieht die Sache leider nich aus

Mein Problem war ja auch hauptsächlich, dass ich dachte mein Objekt müsste wieder nil sein, nachdem ich .Free benutz hab. Weil das ja nich so war, hab befürchtet, ich hätte was vergessen bzw. falsch gemacht. Vorallem was den destructor angeht. Aber wenn das normal is, dass .Free einen "dangling pointer" hinterlässt, is ja alles soweit okay. Muss man ja nur wissen, dann kann man damit umgehen. In der Anleitung is das leider mit keinem Wort erwähnt. Da steht ja extra man soll .Free statt .Destroy nehmen, damit man nich darauf achten muss, ob das Objekt bereits nil is. Vondaher wäre es schlüssig gewesen, wenn das Objekt nach .Free wieder nil wäre. Is halt nich so...

Also noch ma danke für die Hilfe

[Khabarakh]

Zitat von LoRd-MuldeR:

Aber wenn das normal is, dass .Free einen "dangling pointer" hinterlässt, is ja alles soweit okay.

Wenn es anders wäre, wäre Free abnormal . Denn Free ist ja eine Methode von TObject und kann (ohne zusätzlichen Parameter o.Ä.) damit nicht auf die Referenz der Instanz zugreifen und sie nil setzen. Das wäre nur durch Compiler-Magic möglich.

[teebee]

Edit: Vergiss es, war Quatsch...

Gruß, teebee

[Hansa]

Mein Posting hat wohl keiner gelesen. 8) Der Tip kommt von Borland selber ! Destroy und auf NIL setzen ist die Methode, die wasserdicht sein soll. Allerdings habe ich gemerkt, daß egal wie, das alles keine grossen Auswirkungen hat.

[teebee]

Wieso Destroy+Nil "wasserdichter" sein soll als Free+Nil oder FreeAndNil ist mit nicht klar. Free ruft auch nur Destroy auf, prüft vorher aber noch auf self<>nil und verhindert so eine AV, die man sonst bekäme, wenn self schon nil ist.

Gruß, teebee

[marabu]

Hallo Hansa,

Zitat:

Der Tip kommt von Borland selber ! Destroy und auf NIL setzen ist die Methode, die wasserdicht sein soll.

hast du einen Beleg für deine Behauptung? Würde mich sehr interessieren...

marabu

[LoRd-MuldeR]

@Hansa:
Also, dass man TObject.Free und eben *nicht* TObject.Destroy aufrufen soll, steht doch explizit in der offiziellen Delphi Hilfe-Datei. Macht ja auch Sinn, weil - wie schon oft gesagt - TObject.Free auch nichts anderes tut als TObject.Destroy aufzurufen. Der einzige Unterschied: TObject.Free verhindert, dass ein TObject = nil einen AV Error verursacht. Von daher is TObject.Free die sichere Methode!

Aber TObject wird dabei niemals nil, weder bei TObject.Free noch bei TObject.Destroy. Ob man das "zerstörte" TObject nun als "dangling pointer" lässt oder manuell auf nil zurücksetzt, is ja nur dann interessant, wenn man zu einem späteren Zeitpunkt nochmal auf den Pointer zugreift. Also z.B. wenn man noch mal Object.Free ausführt, ohne vorhersagen zu können, ob das Objekt bereits "zerstört" wurde. Ansonsten is das grad egal...

Ob man nun FreeAndNil(Object) oder Object.Free plus Object=nil benutzt kommt auf's gleiche raus. Aber FreeAndNil() is wohl die elegantere Lösung...

Zitat von Delphi Basics:

Example code : Free and nil an object, and then try to do this again

Delphi-Quellcode:

var
  myList : TList;

begin
  // Create the list object
  myList := TList.Create;

  // And now free and nil this object
  FreeAndNil(myList);

  // We can safely do this twice - it ignores nil objects
  FreeAndNil(myList);
end;

No exception occurs - the second FreeAndNil does nothing.

[Grishnak]

@Hansa: es ist mir völlig neu, dass man .Destroy statt .Free benutzen soll!

[LoRd-MuldeR]

Delphi-Quellcode:

unit System

[...]

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