Rekursives Freigeben einer TStringList // Compilerfehler

[Caps]

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

[Uwe Raabe]

Zitat von Delphi.Narium:

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

Delphi-Quellcode:

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

Zitat von Caps:

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

[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 von 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.

Ok, ich glaub das wird OT

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