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
for i:=0 to Count-1 do begin bitte ersetzen durch
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 von DeddyH:

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

Jupp, stimmt...

[Caps]

Zitat von 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?

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 von 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]

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 von Caps:

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.