FreeAndNil geht nicht

[Hansa]

Hi,

ich habe hier einen komplizierten Fall. :P Es geht um diese Stringgrid.Objects. Im Prinzip aber nur um TObject. Wenn ich diese Objects anlege, sie danach mit free freigebe, dann kommen seltsame Fehler. Und zwar daher, weil ich später nochmals auf NIL prüfe. Obwohl die Objekte mit free freigegeben wurden läuft das programm so, als wären sie zumindest nicht NIL. Ich setze sie deshalb zuerst auf NIL und dann erst rufe ich free auf und siehe an : es geht.

Kann mir das mal einer erklären ? :shock: Dieses Verhalten ist anscheinend auch die Ursache für die Existenz von FreeAndNil.

Das hier geht :

Delphi-Quellcode:

procedure TfrmEin.FormHide(Sender: TObject);
var i,j : integer;
begin
  for i := sg.FixedCols to sg.ColCount - 1 do   
    for j := sg.FixedRows to sg.RowCount - 1 do  
      if sg.Objects [i,j] <> nil then begin
        sg.Objects [i,j] := nil;
        sg.Objects [i,j].Free;
      end;
end;

und hier :

Delphi-Quellcode:

procedure TfrmEin.FormHide(Sender: TObject);
var i,j : integer;
begin
  for i := sg.FixedCols to sg.ColCount - 1 do   
    for j := sg.FixedRows to sg.RowCount - 1 do  
      if sg.Objects [i,j] <> nil then begin
        FreeAndNil (sg.Objects [i,j]);
      end;
end;

kommt folgender Fehler :

Zitat:

Zitat von D7-Compiler

[Fehler] ArtNrEin.pas(3118): Konstantenobjekt kann nicht als Var-Parameter weitergegeben werden

[Luckie]

Die Methode Free entfernt nur das Objekt aus dem Speicher. Der Zeiger behält seine zugewiesene Adresse, die natürlich nach dem Aufruf von Free auf einen ungültigen Speicherbereich zeigt.

[Hansa]

Das ist mir mittlerweile auch klar, aber wieso geht FreeAndNil nicht ? Die OH ist da äußerst sparsam. Hätte ich nicht von Hand die TObjects auf NIL gesetzt, dann wäre der Fehler immer noch da. :twisted:

[Sprint]

Zitat:

Zitat von Hansa

Das ist mir mittlerweile auch klar, aber wieso geht FreeAndNil nicht?

Wie soll das denn gehen? FreeAndNil erwartet eine Variable in der eine Objektreferenz steht. Somit kann die Funktion die Variable ein "nichts" geben. Aber du willst keine Variable übergeben, sondern einen Wert der mit der Funktion GetObjects zurückgeben wird und intern aus einer Liste gelesen wird.

[Robert Marquardt]

FreeAndNil hat einen var Parameter, daher kann man natuerlich keine Parameter uebergeben, die zu Funktionen evaluieren.
Eine Property mit Get- und Set-Methode kann daher nicht benutzt werden.

FreeAndNil hat noch einen Nebeneffekt. Erst wird der Parameter auf nil gesetzt und dann Free auf einer Kopie des
Parameters aufgerufen. Das kann zu AVs fuehren, wenn innerhalb des Destruktors aud die Parametervariable zugegriffen wird.

Also
MeinObjekt.Free;
MeinObjekt := nil;
benutzen wenn es mit FreeAndNil nicht geht.

[teebee]

Zitat:

Zitat von Hansa

Das hier geht :

Delphi-Quellcode:

procedure TfrmEin.FormHide(Sender: TObject);
var i,j : integer;
begin
  for i := sg.FixedCols to sg.ColCount - 1 do   
    for j := sg.FixedRows to sg.RowCount - 1 do  
      if sg.Objects [i,j] <> nil then begin
        sg.Objects [i,j] := nil;
        sg.Objects [i,j].Free;
      end;
end;

Das geht nur scheinbar, d.h. Du bekommst zwar keine Fehlermeldung aber Du erzeugst Speicherlecks. Free überprüft nämlich, ob die Referenz nil ist und ruft in diesem Fall Destroy _nicht_ auf. Die Überprüfung auf nil kannst Du Dir daher auch sparen.

Gruß, teebee

[Robert Marquardt]

Das geht natuerlich nicht. Erst auf nil setzen und dann Free aufrufen ist falsch. :wall:

[Hansa]

Und was mache ich jetzt ? Ich habe mir mal den Source von free angesehen :

Delphi-Quellcode:

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

Bei NIL passiert also tatsächlich rein gar nichts. Nun gut. Ich habe gedacht, dann nehme ich eben NIL und Destroy. Und weils so schön ist :lol: habe ich mir das dann auch noch in der RTL angeguckt :

Delphi-Quellcode:

destructor TObject.Destroy;
begin
end;

Und jetzt ? :shock: Fakt ist, daß das Programm so wie ich es gepostet habe so geht. Wie es aussieht weil ich eben den Wert auf NIL setze und ich ihn dadurch abfrage. In der Hilfe steht allerdings auch drin, man müsse selber diese Objects wieder freigeben.

Zitat:

Zitat von OH

Hinweis: Das TStringGridStrings-Objekt ist nicht der Eigentümer der Objekte des Arrays Objects. Objekte, die dem Array Objects hinzugefügt werden, sind auch dann noch vorhanden, wenn das TStringGridStrings-Objekt freigegeben wird. Sie müssen explizit von der Anwendung freigegeben werden.

:wiejetzt:

[sakura]

So:

Delphi-Quellcode:

procedure TfrmEin.FormHide(Sender: TObject);
var i,j : integer;
begin
  for i := sg.FixedCols to sg.ColCount - 1 do   
    for j := sg.FixedRows to sg.RowCount - 1 do  
      if sg.Objects [i,j] <> nil then begin
        sg.Objects [i,j].Free;
        sg.Objects [i,j] := nil;
      end;
end;

...:cat:...

[Hansa]

So wurde mir das von anderer Stelle vorher auch schon geraten. :mrgreen: Mich stört hierbei aber das : "You may use this :" Ich bitte deshalb um Aufklärung, ob das jetzt so wasserdicht ist und warum. Insbesondere, weil ja das aufgerufebe Destroy leer ist. :wiejetzt: <-- der ist manchmal gut. :lol:

[sakura]

Zitat:

Zitat von Hansa

Ich bitte deshalb um Aufklärung, ob das jetzt so wasserdicht ist und warum.

Nichts ist wasserdicht, das ist nun mal das Leben. Aber es ist so gut wie dran, wenn zwischen dem Free und dem nil nicht gerade eine Exception auftritt. Kannst ja noch ein try...finally...end drumsetzen. Dann ist es garantiert nil am Ende, nur ob es Free ist. Wie jetzt ist es vielleicht Free, aber ob es nil ist wenn der PC abraucht :gruebel:

Zitat:

Zitat von Hansa

Insbesondere, weil ja das aufgerufebe Destroy leer ist. :wiejetzt: <-- der ist manchmal gut. :lol:

Das Destroy ist nur die Basis-Funktion, welche als solche leer ist. Im Hintergrund greift aber noch Delphis Compiler-Magic und gibt den nötigen Speicher frei ;)

...:cat:...

[Hansa]

Du meinst also, es wäre gut so ? Na, dann ist ja gut. :mrgreen: Ich vermute mal, destroy ist als abstract definiert und erst im STringgrid wird es mit Leben erfüllt. Werde mal später in der RTL und dann auch in Grids rumgraben und nachsehen. 8)

Jetzt aber noch eine Frage am Rande : solche Sachen sind teilweise, wie hier, nicht so einfach nachzuvollziehen. Kann man das auch testen ? Früher hatte es gereicht, das mit memavail zu machen. Wie kann man so was machen ? Memcheck vielleicht (oder wie das heißt) ? In dem konkreten Fall hier kann es passieren, daß mehrmals zig Eingaben in das Grid gemacht werden. Da könnten schnell 1000 oder mehr Zeilen zusammenkommen. Schleppe ich jetzt noch zu jeder Zelle ein TObject mit, dann wäre es schon interessant zu wissen, wie sich das auf den Speicher auswirkt, sofern das free vergessen wird oder sonst was verändert wird.

[Touchdown]

Mach einen Typcast drauf und gut is :-D

Delphi-Quellcode:

FreeAndNil (TObject(sg.Objects [i,j]));

Hab es jetzt nicht getestet aber sollte gehen.

Es gibt ja keine Objekte die nicht von TObject abgeleitet sind, also unsauer ist es deshalb auch niemal.

[Hansa]

Aha, ja, wer weiß ? 8) Ich warte lieber mal noch auf Sakura. :mrgreen:

[Sprint]

Zitat:

Zitat von Hansa

dann wäre es schon interessant zu wissen, wie sich das auf den Speicher auswirkt, sofern das free vergessen wird oder sonst was verändert wird.

Du kannst auch deine Objekte schon in TObjectList verwalten, dann brauchst du dich nicht selber drum zu kümmern.

[sakura]

Zitat:

Zitat von Touchdown

Mach einen Typcast drauf und gut is :-D
Hab es jetzt nicht getestet aber sollte gehen.

Geht nicht, das FreeAndNil eine Variable erwartet. Du kannst also auch folgendes machen:

Delphi-Quellcode:

var
  O: TObject;
...

  O := sg.Objects [i,j];
  sg.Objects [i,j] := nil;
  FreeAndNil(O);

Nur: Das bringt keinen Vorteil :roll:

...:cat:...

[teebee]

Zitat:

Zitat von Hansa

Jetzt aber noch eine Frage am Rande : solche Sachen sind teilweise, wie hier, nicht so einfach nachzuvollziehen. Kann man das auch testen ? Früher hatte es gereicht, das mit memavail zu machen. Wie kann man so was machen ? Memcheck vielleicht (oder wie das heißt) ?

Ich benutze sehr gerne MemProof.
Gruß, teebee