FreeAndNil vs TObject.free

[DataCool]

Hi Leute,

mal ne grundsätzliche Frage :

Wenn ich mir den Quellcode von der Procedure FreeAndNil anschaue, macht diese ja nicht anderes als das Free des Objects aufzurufen und dann den Zeiger auf nil zu setzen.
Wann ist das sinnvoll ?

Gruß Data

[Sanchez]

Hallo,

Es ist dann sinnvoll, wenn du ein Objekt freigeben und den Zeiger auf nil setzen willst.
Es spart einfach eine Zeile bzw vergisst man das nil-setzen nicht.

grüße, daniel

[DataCool]

Hi,

das habe ich mir auch schon gedacht :mrgreen:

nächste Frage :

Macht folgender Source Sinn ? :

Code:

procedure SinnOderSinnlos;
Var strL : TStringList;
begin
   strL := TSTringList.create;
   try
      strL.Add('Bla');
      // ..... weitere verarbeitungen mit der Stringliste
   finally
      FreeAndNil(strL);   // oder strL.free
   end;
end;

Bzw. wann macht es Sinn, eine Variable auf Nil zu setzen, außer zu zu vergleichszwecken ?

Gruß Data

[Sanchez]

Ich würde sagen, dass es nur bei Zeigern die später noch verfügbar sind Sinn macht. Also bei Klassenobjekten und globalen Objekten (wenn sie sich nicht vermeiden lassen).

Bei lokalen Objekten eher weniger

[Chewie]

Du hast Recht, die Variable zusätzlich noch auf nil zu setzen, macht nur Sinn, wenn du danach prüfen willst, ob das Objekt besteht oder nicht. Ansonsten sind es ein paar verschwendete Takte ;-).

[Sourcemaker]

Hi,

innerhalb einer kleinen Prozedure dürfte der Sinn begrenzt sein wenn es aber eine private Variable der Form ist und du an unterschiedlichen Programmstellen auf Initialisierung der Variable testest steigt der Sinn erheblich.

Delphi-Quellcode:

if Var = nil then
   Var := Ini();

Grüße

Frank

[DataCool]

Ok, so habe ich das bis jetzt auch immer behandelt !

Wenn irgentwo anders die Var geprüft wird dann auf nil setzen, ansonsten Free verwenden.

Habe nur neulich eins meiner Progs mit memproof getestet und da merkert er das(nicht auf nil setzen) an,
deshalb meine Frage !

Danke Data

[s14]

@Sanchez
geht man in Österreich schon mit 42 in Pension? Da muss ich ja noch schnell Umsiedeln 8)

[choose]

Hallo DataCool,

dieses Thema wurde auch schon in diesem Thread (etwas weiter unten) diskutiert.

Ich vertrete generell die Meinung, dass Referenzen/Pointer entweder gültig oder nil sein sollten. Der "hässliche Zwischenzustand" birgt nur in wenigen Ausnahmefällen Vorteile, führt aber auf der anderen Seite zu häufig zu Problemen und ist im Design von Sprachen wie Smalltalk, Java oder C# vermieden worden :)

[Luckie]

Ich habe mir angewöhnt FreeAndNil zunehmen, auch wenn ich den zeiger nachher nicht auf nilk testen will. einfach aus dem Grund um es mir anzugewöhnen, damit für den fall, dass ich es mal brauche es automatisch mache.

[DataCool]

Da bin ich auch gerade bei mir das anzugewöhnen :mrgreen:

[Bernd Ua]

Hi,

Zitat:

...Java oder C# vermieden worden

@choose : Na dann greif mal im Finalize einer C#-Klasse auf Objektreferenzen zu,
die diese Klasse hält ( bzw hielt). Wenn der Garbage Collector die referenzierten
Klassen zufällig vorher entsorgt hat , hast Du exakt diesen Zwischenzustand

Grüsse Bernd

[Luckie]

Aaah, genau da bin ich gerade.

Code:

      private void btnChooseFolder_Click(object sender, System.EventArgs e)
      {
        FolderBrowserDialog fbd;
        fbd = new FolderBrowserDialog();
        fbd.Description = "Wählen sie ein Zielverzeichnis für die Dateien aus.";
        if (fbd.ShowDialog() == DialogResult.OK)
        {
          txtFolder.Text = fbd.SelectedPath;
        }
      }

Der GarbageCollector gibt doch das Objekt für mich wieder frei oder? OK ist etwas offtopic.

[Bernd Ua]

Hallo Luckie

idR gibt der Garbage Collector die Klasse irgendwann wieder frei.
Klassen, die deterministisch freizugebende Ressourcen verwenden und bei denen
man selber explizit Close bzw Dispose aufrufen sollte, implementieren (bzw sollten)
die Schnittstelle IDisposable implementieren.
(Dispose/bzw Close geben nur die Ressourcen frei, nicht das objekt selbst).

Um den Bogen zum Thema des Forums (Delphi) wieder zu kriegen - für eine Delphi Klasse
in Delphi für .NET, in der Destruktor korrekt überschrieben ist baut der Compiler automatisch
nach aussen das Interface IDisposable ein ( geht auch schon mit dem Preview) und
Destroy wird quasi zur Implementierung von Dispose
( was deutlich anders ist als in C# wo der Pseudodestruktor ~Klassenname in Wirklichkeit zu
Finalize mit automatischem try..finally mutiert)

Bernd

[choose]

Zitat:

Zitat von Bernd Ua

[...]greif mal im Finalize einer C#-Klasse auf Objektreferenzen zu [...]. Wenn der Garbage Collector die referenzierten Klassen zufällig vorher entsorgt hat, hast Du exakt diesen Zwischenzustand

Erwischt ;)

Auch in Java gibt es mit anonymen und nachgeladenen Klassen seine Tücken und in Smalltalk purzelt's mitunter messageNotUnderstood: Nachrichten, wenn man dynamische Proxy-Klassen implementiert...
Der "Anwendungsentwickler" sollte diese Dinge jedoch nach Möglichkeit nicht sehen, so dass er, im Gegensatz zu C/C++, Delphi & Co. vor "Flüchtigkeitsfehlern" bewart wird (sinnvolle Ausnahmen gibt es immer s.o.).
Solange ich deshalb ohne SmartPointer in C++ oder ohne IInterface-Referenzzählern in Delphi arbeite, verwende ich immer Konstrukte, die eine Referenz nullen, damit auch meine Umwelt (drei Zeilen später) weiß, was ich meinte...

[Bernd Ua]

Zitat:

Auch in Java gibt es mit anonymen und nachgeladenen Klassen seine Tücken und...

Tröstlich zu hören :mrgreen:
dann kann ich mich ja richtig freuen, das die DB2 Oberfläche(Java) beim Beenden "nur"
Javalang:NullPointerExeceptions wirft und nicht Schutzverletzungen <bg>

Bernd

Programmieren ohne Pointer ist wie safer sex - fühlt sich irgendwie doof an :roll:

[Luckie]

Zitat:

Zitat von Bernd Ua

Programmieren ohne Pointer ist wie safer sex - fühlt sich irgendwie doof an :roll:

Ich schmeiß mich weg. :mrgreen:

[dizzy]

Zitat:

Programmieren ohne Pointer ist wie safer sex - fühlt sich irgendwie doof an.

Sehr geil!!! Jetzt muss ich nurnoch gucken, wie ich mich wieder "ent-kringel"... :gruebel:. Macht sich heut abend beim Italiener nicht so gut *g*.