Rekursives Freigeben einer TStringList // Compilerfehler

[Caps]

Hallöle,

ich möchte mit einer Prozedur eine Stringliste rekursiv freigeben.

Hintergrund:
Ich verwende Stringlisten, an deren Objects-Eigenschaft(en) weitere Stringlisten hängen, so dass sich ein Baum als Datenstruktur ergibt.

Die Funktion ist angelehnt an FreeAndNil() und sieht folgendermaßen aus:

Delphi-Quellcode:

procedure FreeStringList(var List: TStringList);
var
   i: Integer;
begin
  if List <> nil then with List do begin
    if Count > 0 then begin
      for i:=0 to Count-1 do begin
        if Objects [i] <> nil then begin
          if Objects [i].ClassNameIs('TStringList') then
            // Unterknoten freigeben...
            FreeStringList(TStringList(Objects [i])) // Konstantenobjekt kann nicht als Var-Parameter weitergegeben werden
          else begin
            // Blatt freigeben...
            Objects [i].Free;
            Objects [i] := nil;
          end;
        end;
      end;
    end;
    FreeAndNil(List);
  end;
end;

Ich habe zwei Probleme damit, die sich gegenseitig ausschließen, je nachdem ob ich den Parameter List als var-Parameter oder als normale Objektreferenz (ohne var) übergebe:

1) Übergebe ich List mit var, erhalte ich die im Code als Kommentar ersichtliche Fehlermeldung.
2) Übergebe ich List ohne var, so wird die übergebene Referenz nicht auf nil gesetzt, d.h. nach Anwendung der Funktion auf eine Stringliste ist zwar das Objekt weg, aber die Referenz nicht nil.

Ich stehe ein wenig auf dem Schlauch.
Wie kann ich denn meine Datenstruktur nun rekursiv freigeben?

Grüße!
Caps

[DeddyH]

Welchen tieferen Sinn soll es haben, die "Unterobjekte" auf nil zu setzen? Eine Freigabe mit anschließendem nilen der Hauptliste sollte doch ausreichen, oder?

[Papaschlumpf73]

Ich antworte mal ungefragt auf Problem 3. Die Liste muss quasi rückwärts von hinten gelöscht werden.

Diese Zeile

Delphi-Quellcode:

for i:=0 to Count-1 do begin

bitte ersetzen durch

Delphi-Quellcode:

for I:=Count-1 downto 0 do begin

[DeddyH]

Wieso, es wird ja nichts gelöscht, sondern nur freigegeben?

[edit] Geht es eigentlich wirklich um Delphi 5? Oder ist es in Wirklichkeit ein aktuelleres Delphi, wo es schon die OwnsObjects-Eigenschaft gibt? [/edit]

[Papaschlumpf73]

Zitat:

Zitat von DeddyH (Beitrag 1467320)

Wieso, es wird ja nichts gelöscht, sondern nur freigegeben?

Jupp, stimmt...

[Caps]

Zitat:

Zitat von DeddyH (Beitrag 1467318)

Welchen tieferen Sinn soll es haben, die "Unterobjekte" auf nil zu setzen? Eine Freigabe mit anschließendem nilen der Hauptliste sollte doch ausreichen, oder?

Ist das so? Ich war mir nicht ganz sicher, ob der Destruktor von TStringList die Objekte ebenfalls freigibt. Ich glaube dann hab ich die Hilfe falsch verstanden, da steht "Destroy gibt den Speicherplatz frei, der für die String-Liste und die Objektreferenzen reserviert war" - das hab ich nur auf die Pointer bezogen, nicht auch auf die Objekte selbst.

Grüße!

[Caps]

Zitat:

Zitat von DeddyH (Beitrag 1467320)

Wieso, es wird ja nichts gelöscht, sondern nur freigegeben?

[edit] Geht es eigentlich wirklich um Delphi 5? Oder ist es in Wirklichkeit ein aktuelleres Delphi, wo es schon die OwnsObjects-Eigenschaft gibt? [/edit]

Nein, tatsächlich D5.

[jziersch]

Ich würde hier aber keine TStringList verwenden sondern eine Ableitung davon in der Du in Destroy-override Deine Unterlisten selber frei gibst. Dann würde ein List.Free bzw. FreeAndNil(List) reichen und Du kannst dir das "if Objects [i].ClassNameIs('TStringList')" sparen. Besser wäre übrigens "is"

[Caps]

Stimmt. Destruktor überschreiben. Hm, danke, ich glaube jetzt wird's irgendwie klappen.

Danke und Grüße!
Caps

[Lemmy]

Zitat:

Zitat von Caps (Beitrag 1467317)

2) Übergebe ich List ohne var, so wird die übergebene Referenz nicht auf nil gesetzt, d.h. nach Anwendung der Funktion auf eine Stringliste ist zwar das Objekt weg, aber die Referenz nicht nil.

darüber gibt es unterschiedliche Meinungen - da Du in aller Regel anschließend nicht mehr auf die Liste zugreifst, macht es auch nix aus, wenn da Blödsinn drin steht.
Wenn Du anschließend (d.h. nach der Freigabe) darauf zugreifst, dann hast Du einen anderen (!) Fehler in der Anwendung.
Leider finde ich die beiden BlogPosts von Nick Hodges zu dem Thema nicht mehr.

[Caps]

Leider greife ich hinterher noch drauf zu, vorher prüfe ich aber, ob die Liste nil ist, und da hat's geknallt ^^.

[Lemmy]

um es mal zu umschreiben:
es ist keine gute Idee, erst die Wohnung in die Luft zu jagen und sich dann zu wundern, dass man mit dem Festnetzanschluss bei der Feuerwehr nicht mehr durch kommt.

Wenn Du also die TStringList incl. den Kind-Elementen frei gibts - welchen genauen Grund mag es geben anschließend nochmal auf die Kindelemente zuzugreifen? An der Stelle liegt dein Fehler, nicht aber darin ob bei der Freigabe der Kindelemente nun NIL zugewiesen wurde oder eben nicht...

[Caps]

Ja, ich weiß was du meinst.
Die Stelle war ebenfalls ein Destruktor, der nochmal geprüft hat, ob das Objekt nil ist, und wenn nicht, Free aufruft. Du hast schon recht, dass das eigentlich nicht nötig sein sollte, es ist dennoch momentan so.
Mein Problem war das rekursive Freigeben einer Stringliste.

Grüße!

[himitsu]

Wenn man nur mit TComponents arbeitet, dann kann man deren Notifications benutzen.

Da können sich Andere bei der Klasse registrieren und werden informiert, wenn die Komponente freigegeben wird, um die Referenz bei sich zu entfernen.
z.B. TEdit<->TDataSource<->TDataSet oder TButton<->TImageList/TPopup, ....
Man löscht die ImageList und das Property in der anderen Komponente wird NIL.

Es gibt auch eine TComponentList, die das nutzt.
Da kann man bei Verschwinden der Komponente den Eintrag in der Liste auf NIL setzen oder gleich komplett entfernen lassen.

[Delphi.Narium]

Ursprünglich ging es doch eigentlich darum, dass es einen Kompilierfehler gab. Bei meinem ollen Delphi 7 gibt es den mit diesem veränderten Code nicht mehr. Reicht das zur Problemlösung?

Delphi-Quellcode:

procedure FreeStringList(var List: TStringList);
var
   i      : Integer;
   myList : TStringList;
begin
  if Assigned(List) then begin
    for i := 0 to List.Count - 1 do begin
      if Assigned(List.Objects[i]) then begin
        if List.Objects[i] is TStringList then begin
          myList := TStringList(List.Objects[i]);
          // Unterknoten freigeben ...
          FreeStringList(myList);
        end else begin
          // Blatt freigeben ...
          FreeAndNil(List.Objects[i]);
        end;
      end;
    end;
    FreeAndNil(List);
  end;
end;

Wenn ein Funktionsparameter mit var angegeben wird, dann kann man da halt keinen Cast ala TStringList(irgendeinobjekt) reingeben (derweil das ist dann const), man muss sich die Mühe machen, dort eine Variabel zu übergeben. Es ist also der Aufwand einer Variabelndeklaration des passenden Types und eine Zuweisung des Casts TStringList(irgendeinobjekt) an die entsprechende Variabel nötig. Die Variabel kann man dann problemlos in der Funktionsaufruf schreiben und der Compiler ist's zufrieden.

Und wie immer: Man kann grundsätzlich jedes Problem auch irgendwie anders lösen, aber vielleicht reicht diese einfache Änderung ja auch aus ;-)

[Caps]

Moin,

nur zur Unterhaltung: es geht doch, wenn auch nur mit abenteuerlichem Herumgecaste:

Delphi-Quellcode:

procedure FreeStringList(var List);
var
  i: Integer;
  Obj, Obj_: TObject;
  List_: TStringList;
begin
  Obj := TObject(List);
  if Obj <> nil then begin
    if Obj is TStringList then begin
      List_ := TStringList(Obj);
      with List_ do begin
        if Count > 0 then begin
          for i:=0 to Count-1 do begin
            if Objects [i] <> nil then begin
              Obj_ := Objects [i];
              FreeStringList(Obj_);
            end;
          end;
        end;
      end;
    end;
    TObject(List).Free;
    TObject(List) := nil;
  end;
end;

lg Caps

[Uwe Raabe]

Dieser Code

Delphi-Quellcode:

              Obj_ := Objects [i];
              FreeStringList(Obj_);

sorgt nicht dafür, das

Delphi-Quellcode:

Objects[i]

hinterher nil ist! Lediglich

Delphi-Quellcode:

Obj_

ist dann nil.

Die

Delphi-Quellcode:

Objects[]

Werte in einer TStringList lassen sich nur durch eine direkte Zuweisung auf nil setzen. Eine Übergabe als var Parameter, ob typisiert oder untypisiert, lässt der Compiler aus genau diesem Grund nicht zu.

[Caps]

Stimmt, ich merk's. Schade ^^

[Caps]

Der Vollständigkeit halber meine jetzige Lösung, falls jemand ein ähnliches Problem hat:

Neuer Typ:

Delphi-Quellcode:

TStringTree = class(TStringList)
  public
    destructor Destroy; override;
end;

Und hier der Destruktor:

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i:=0 to Count-1 do begin
    if Objects [i] <> nil then begin
      if Objects [i] is TStringTree then
        TStringTree(Objects [i]).Free
      else
        Objects [i].Free;
      Objects [i] := nil;
    end;
  end;

  inherited;
end;

Approved? :)

lg Caps

[Uwe Raabe]

Das geht auch einfacher:

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i:=0 to Count-1 do begin
    Objects [i].Free;
    Objects [i] := nil;
  end;

  inherited;
end;

[DeddyH]

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i := 0 to Count-1 do 
    Objects[i].Free;
  inherited;
end;

Sollte dasselbe bewirken, nur kürzer.

[Delphi.Narium]

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i := 0 to Count - 1 do FreeAndNil(Objects[i]);
end;

Ohne die Abfrage, ob's nun 'ne TStringList ist oder nicht, hat es den Vorteil, dass alle Objekte freigegeben werden und nicht nur die Stringlisten. Spart (vermutlich) das eine oder andere Speicherleck ;-)

[Caps]

Ok, aber wenn man nur den Destruktor von TObject aufruft, dann wird doch der Baum nicht rekursiv freigegeben?

[Caps]

Zitat:

Zitat von Delphi.Narium (Beitrag 1467421)

Ohne die Abfrage, ob's nun 'ne TStringList ist oder nicht, hat es den Vorteil, dass alle Objekte freigegeben werden und nicht nur die Stringlisten. Spart (vermutlich) das eine oder andere Speicherleck ;-)

Aber in #19 gebe ich doch alle Objekte frei.

[DeddyH]

Genau deshalb soll der Destruktor grundsätzlich überschrieben werden und nicht verdeckt. Probier es doch einfach mal aus.

[Caps]

Zitat:

Zitat von Uwe Raabe (Beitrag 1467416)

Das geht auch einfacher:

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i:=0 to Count-1 do begin
    Objects [i].Free;
    Objects [i] := nil;
  end;

  inherited;
end;

Aber wird bei Objects [i].Free nicht nur der Destruktor von TObject aufgerufen?
Es soll ja aber mein Destruktor aufgerufen werden. Warum muss ich da nicht casten?

[Caps]

Zitat:

Zitat von DeddyH (Beitrag 1467426)

Genau deshalb soll der Destruktor grundsätzlich überschrieben werden und nicht verdeckt. Probier es doch einfach mal aus.

Achso, es gibt dann in der ganzen Hierarchie nur noch exakt einen Destruktor?
Das wusste ich nicht. Ok, dann macht es Sinn :). Man lernt nie aus.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1467421)

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i := 0 to Count - 1 do FreeAndNil(Objects[i]);
end;

Es fehlt nicht nur der Aufruf von inherited, sondern unter 10.3 und älter compiliert es gar nicht.

Der Code von DeddyH ist vollkommen ausreichend.

Zitat:

Zitat von DeddyH (Beitrag 1467418)

Delphi-Quellcode:

destructor TStringTree.Destroy;
var
  i: Integer;
begin
  for i := 0 to Count-1 do 
    Objects[i].Free;
  inherited;
end;

Zitat:

Zitat von Caps (Beitrag 1467427)

Aber wird bei Objects [i].Free nicht nur der Destruktor von TObject aufgerufen?
Es soll ja aber mein Destruktor aufgerufen werden. Warum muss ich da nicht casten?

Free ruft Destroy auf und das ist

Delphi-Quellcode:

virtual

.

[Caps]

Ok, ich glaube da komme ich an die Grenzen meiner OOP-Kenntnisse ^^.
Es gibt also nicht nur ein Destroy, weil inherited ja ein Vorfahr-Destroy aufruft, oder?
Ich glaube jetzt bin ich verwirrter als vorher :shock:

[DeddyH]

Virtuelle und dynamische Methoden können überschrieben werden. Wenn eine solche Methode einer Instanz aufgerufen wird, wird die Virtual Method Table (VMT) durchlaufen, ausgehend von der Klasse der Instanz in der Hierarchie aufsteigend, bis eine Implementation gefunden wird. Die wird dann abgearbeitet. Normalerweise möchte man die Methode aber nicht komplett ersetzen, sondern nur erweitern, weswegen man dann inherited aufruft, um die nächste Implementation in den höher gelegenen Klassen auszuführen.

[Caps]

Zitat:

Zitat von DeddyH (Beitrag 1467432)

Virtuelle und dynamische Methoden können überschrieben werden. Wenn eine solche Methode einer Instanz aufgerufen wird, wird die Virtual Method Table (VMT) durchlaufen, ausgehend von der Klasse der Instanz in der Hierarchie aufsteigend, bis eine Implementation gefunden wird. Die wird dann abgearbeitet. Normalerweise möchte man die Methode aber nicht komplett ersetzen, sondern nur erweitern, weswegen man dann inherited aufruft, um die nächste Implementation in den höher gelegenen Klassen auszuführen.

Ok, ich glaub das wird OT :o

Aber warum wird dann bei Objects [i].Free der Destruktor von TStringTree aufgerufen?
Woher weiß denn der Compiler, welcher Typ da drin steckt?
Also was ich meine ist: wenn ich von einer Basisklasse zwei verschiedene Klassen ableite, und dann den Destruktor der Basisklasse (TObject) aufrufe, dann kann der Compiler doch gar nicht entscheiden, welcher Typ nun wirklich an dem Zeiger dranhängt, oder bin ich völlig abwegig?
Vermutlich müsste das mal in einen anderen Thread (OOP oder so ^^)

[himitsu]

Da außen die Variable NIL werden soll, das aber beim Property "Objects" nicht geht, macht es sich mit "einer" Funktion nicht so gut.

Delphi-Quellcode:

procedure FreeStringList(const [ref] List: TStrings);
procedure Walk(Obj: TObject);
  begin
    if Obj is TStrings then
      for var Obj2 in TStrings(Obj).ToObjectArray do
        Walk(Obj2);
    Obj.Free;
  end;
begin
  // wie FreeAndNil : modern, typsicher mit CONST-REF -> https://dalijap.blogspot.com/2020/06/magic-behind-freeandnil.html
  var Temp := List;
  TObject(Pointer(@List)^) := nil;
  Walk(Temp);
end;

bzw.

Delphi-Quellcode:

procedure FreeStringList(var List{: TStrings});
procedure Walk(Obj: TObject);
  var
    i: Integer;
  begin
    if Obj is TStrings then
      for i := TStrings(Obj).Count-1 downto 0 do
        Walk(TStrings(Obj).Objects);
    Obj.Free;
  end;
var
  Temp: TStrings;
begin
  // wie FreeAndNil : alt, mit VAR im Funktionskopf
  Temp := TStrings(List);
  List := nil;
  Walk(Temp);
end;

[DeddyH]

Das wird Delphi 5 aber freuen, was es plötzlich so alles kann :stupid:

[himitsu]

Jupp :angle: