![]() |
Frage zu FreeAndNil
Hi,
ist das nicht egal ob ich object.free; mache oder FreeAndNil(object)? Die sachen liegen auf dem stack. Das letzte command bevor die sub verlassen wird, ist object.free; Macht es sinn sachen die nicht auf dem stack liegen mit FreeAndNil freizugeben? Macht das nicht auch nur ein .free und dann object:=nil? Danke im voraus |
Re: Frage zu FreeAndNil
Lokale Objektvariablen die am Ende der Methode/Prozedur freigegeben werden sollen brauchen kein FreeAndNil.
FreeAndNil ist eigentlich nur notwendig, wenn du einer Objektvariable im Laufe der Zeit immer neue Objekte zuweist um nachschauen zu können, ob gerade ein Objekt zugewiesen ist oder nicht. |
Re: Frage zu FreeAndNil
Ah, danke. Wieder was gelernt :) Dann kann ich ja alles so lassen. Weil nach nil frage ich nirgends ab.
|
Re: Frage zu FreeAndNil
Ich habe mir aber trotzdem angewöhnt FreeAndNil zu benutzen, dann ist man immer auf der sicheren Seite.
|
Re: Frage zu FreeAndNil
Wenn man irgendwo prüft, ob das Objekt existiert, z.B. ala if assigned(obj) then, dann muß man die Variable nach dem Freigeben auch auf NIL setzen.
dieses gibt nur frei
Delphi-Quellcode:
dieses würde zwar theoretisch auf NIL setzen, aber wenn es beim .Free zu einer Exception kommt, dann gibt es später womöglich nette Probleme
obj.Free;
Delphi-Quellcode:
also macht sich Dieses dann schon besser, weil es erst auf NIL setzt und danach .Free aufruft
obj.Free;
obj := nil;
Delphi-Quellcode:
FreeAndNil(obj);
|
Re: Frage zu FreeAndNil
Hmmm, denn frag ich mal gezielter.
Was macht FreeAndNil? Mehr als
Delphi-Quellcode:
mach es doch nicht, oder testet der noch irgendwas? Weil wenn nicht, ist es in meinem falls wurscht, da es auf dem stack liegt und nachdem ret eh nimmer verfügbar ist.
object.free;
object:=nil; EDIT: da war himitsu schneller :P |
Re: Frage zu FreeAndNil
Zitat:
Strg + Linksklick auf FreeAndNil
Delphi-Quellcode:
was logisch gesehn in etwa Diesem entsprechen würde
procedure FreeAndNil(var Obj);
var Temp: TObject; begin Temp := TObject(Obj); Pointer(Obj) := nil; Temp.Free; end;
Delphi-Quellcode:
procedure FreeAndNil(Obj: TObject);
begin try Obj.Free; finally Obj := nil; end; end; |
Re: Frage zu FreeAndNil
Zitat:
|
Re: Frage zu FreeAndNil
Zitat:
Eine schöne, lange Diskussion dazu hier: "FreeAndNil is often sign of wrong design - did anyone really read the blog?" ![]() Viele Grüße, |
Re: Frage zu FreeAndNil
Darüber lässt sich streiten.
Szenario: Ein Objekt verwaltet mehrere Objektvariablen als Felder in sich selbst. Alle diese Objekte greifen über einen zb. Owner/Parent auf diese übergeordnete Objekt zu. Diese untergeordneten Objekte nutzen ihren Owner/Parent um ihrerseits auf die anderen Objekte des Parten/Owners zugreifen zu können. Soweit ein ganz legales und OOP konformes Konstrukt. Der Parent kann nun nicht zum gleichen Zeitpuinkt seine Objektfelder freigeben, er wird es immer sequentiell ausführen müssen. Die untergeordneten Objekte des Parents fragen ihrerseits mit Assigned(Parent.Objekt_A) bei einem Zugriff ab ob das gewünschte Objekt überhaupt erzeugt wurde. Nun passiert es gerade bei komplexeren Klassenstrukturen wie zb. Windows Controls das ein asynchrones Messagehandling benutzt wird. Also selbst beim Freigeben eines spezifischen Objektes kann es durchaus sein das dieses über Parent.Objekt_A noch weitere Behandlungen durchführt. Würde man im Destructor des parents nun njicht mit FreeAnNil() die Objekte freigeben dann funktioniert bei der Freigabe des nachfolgenden Objektes (Objekt_B im Parent) eine Abfrage wie Assignend(Parent.Objet_A) nicht korrekt. Man kann nun behaupten das das alles "schlechtes Design" wäre. Ich stehe auf folgendem Standpunkt: 1.) mache gutes Design 2.) benutzte ein zusätzlich Sicherheitsnetz, das kann nie schaden und kostet nichts Wer von sich behauptet er benötigt kein - FreeAndNil() - if Assigned() then - if Objekt is Klasse then weil sein Design immer ein gutes Design ist das dies ja nicht nötig hat, der hat noch nie im Team gearbeite, noch auf Sourcen/Code anderer Programmierer aufsetzten, weiterentwickeln müssen und ist ergo arrogant und fern der Realitäten. Gruß Hagen PS: oder er benutzt eine Programmiersprache bei der all diese Probleme erst garnicht auftreten können, wozu Delphi nunmal nicht gehört. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:02 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz