Objectlist rekursiv free?

[moelski]

Moin !

Habe da eine Objektliste die ich mit Objektinstanzen fülle.
Diese Objektinstanzen haben wiederum eine Property "Subitems" welches dann wieder eine TObjectList ist.

Damit kann man verschachtelte Objektstrukturen erzeugen. Funzt auch soweit.

Wenn ich nun aber "ReportMemoryLeaksOnShutdown := True" setze, dann bekomme ich Leaks.
Ich habe mal eine kleine Testanwendung zusammengestochert die das verdeutlicht.
-> Siehe Anhang.

FreeAndNil(TestList) bewirkt nur ein Free für die Objekte die in TestList vorhanden sind.
Ich hätte erwartet das die SubItems (property ITEM_SubItems : TObjectList) auch ein Free erfahren.
Dem ist aber nicht so :(

Muss ich jetzt wirklich rekursiv durch meine Objektlisten und überall ein Free aufrufen oder gibt es für TObjectList einen Automatismus der alle SubItems gleich mit zieht?

[mleyen]

Les dir am besten noch einmal die Hilfe zu OwnsObjects durch.

[moelski]

Moin !

Du hast Recht.
Oh Mann schon das zweite Mal über diese "Falle" gestolpert :oops:

Danke jedenfalls.

[moelski]

Nur der Vollständigkeit halber ...
So klappts dann auch mit dem rekursiven Free:

Delphi-Quellcode:

procedure FreeLists(List : TObjectList);
var
  I       : Integer;
  Pi      : TPI_Root;
  SubList : TObjectList;
begin
  for I := List.Count - 1 downto 0 do begin
    SubList := TPI_Root(List.Items[I]).ITEM_SubItems;
    if SubList.Count > 0 then
      FreeLists(SubList);

    Pi := TPI_Root(List[i]);
    List.Delete(I);
    if List.OwnsObjects = False then
      Pi.Free;
  end;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeLists(TestList);
  TestList.Free;
end;

[Sir Rufo]

Das was du da machst ist irgendwie völlig sinnentleert.

Wenn ich eine ObjectList habe und setze OwnsObjects auf True, dann signalisiere ich: Ja, diese Liste kümmert sich irgendwann um das Entfernen aus dem Speicher.
Ist OwnsObjects auf False, dann heißt das, das die Objekte hier zwar aufgeführt werden, aber jemand anders kümmert sich um das Freigeben.

Was du hier machst, ist einen Designfehler in deiner Anwendung zu beheben und kann auch zu einem Zugriffsfehler führen.

Delphi-Quellcode:

OList1 := TObjectList.Create( True );
OList2 := TObjectList.Create( False );

Obj := TFooObj.Create;

OList1.Add( Obj );
OList2.Add( Obj );

for Obj in OList do
  begin
    OList2.Remove( Obj );
    if not OList2.OwnsObjects then
      Obj.Free; // Jetzt rummst es, da das Objekt OList1 gehört
  end;

Und hierzu

Delphi-Quellcode:

for I := List.Count - 1 downto 0 do begin

sei folgendes gesagt:
Der Compiler entscheidet ob vorwärts oder rückwärts gezählt wird, somit kann auch dieses hier in die Hose gehen

[moelski]

Moin Rufo,

Zitat:

aber jemand anders kümmert sich um das Freigeben.

Das versuche ich ja eben.

Delphi-Quellcode:

TForm1.FormDestroy

Das ich derzeit den Aufruf von hier starte ist im Moment rein für den Test gedacht.

Was wäre denn eine bessere Variante Objekte freizugeben die nicht einer ObjectList gehören?

[shmia]

Zitat:

Zitat von moelski (Beitrag 1063216)

Was wäre denn eine bessere Variante Objekte freizugeben die nicht einer ObjectList gehören?

Um was für eine Art von Objekten handelt es sich denn?
Ich frage hier nach den Namen der Klassen.

[chaosben]

OT:

Zitat:

Zitat von Sir Rufo (Beitrag 1063211)

Und hierzu

Delphi-Quellcode:

for I := List.Count - 1 downto 0 do begin

sei folgendes gesagt:
Der Compiler entscheidet ob vorwärts oder rückwärts gezählt wird, somit kann auch dieses hier in die Hose gehen

Das ist doch ein Scherz, oder? Wenn nicht, würde ich das gern in einem neuen Thread besprechen.

[Neutral General]

Zitat:

Zitat von chaosben (Beitrag 1063221)

OT:

Zitat:

Zitat von Sir Rufo (Beitrag 1063211)

Und hierzu

Delphi-Quellcode:

for I := List.Count - 1 downto 0 do begin

sei folgendes gesagt:
Der Compiler entscheidet ob vorwärts oder rückwärts gezählt wird, somit kann auch dieses hier in die Hose gehen

Das ist doch ein Scherz, oder? Wenn nicht, würde ich das gern in einem neuen Thread besprechen.

Ist beides nicht ganz korrekt. Der Compiler zählt nur rückwärts, wenn es keinen Unterschied macht ob die Schleife vorwärts oder rückwärts läuft (weils schneller ist). In diesem Fall gibt es nichts zu befürchten. Die Schleifen würde immer rückwärts laufen.

[chaosben]

Danke. :)

[moelski]

Moin !

Ok dazu muss ich wohl etwas ausholen und ein bisserl beschreiben wie ich das einsetze ...

In der Anwendung gibt es mal eine ProjektListe (TObjectList).
Darin erstelle ich Instanzen von Projektklassen - Item_Project.

In Item_Project kann man in einer TObjectList wiederum Subelemente einhängen.
z.B. eine Instanz der Klasse Item_Device.

Und Item_Device kann man ebenfalls Unterelemente zuweisen wie z.B. Item_Chart.

Jede dieser Item_... Klassen ist abgeleitet von einer Basisklasse (Item_Root).
Diese Klasse hat eine Property:

Delphi-Quellcode:

property ITEM_SubItems : TObjectList        read FITEM_SubItems    write FITEM_SubItems;

Damit lassen sich dann eben verschachtelte Strukturen erzeugen:

Code:

Item_Project
--> Item_Device
-->--> Item_Chart

Ob dieses Konstrukt nun der beste weg sei, das sei mal dahingestellt. Für mich erfüllt es seinen Zweck :)

Leider komme ich nicht drumrum einzelne Objecte in verschiedenen Listen einzufügen. Deshalb nutze ich dort dann OwnsObject = False.

Nur Sir Rufo hat schon Recht ... Das führt zu Problemen wenn man einen ganzen Projekt Tree (Ab Item_Project) entfernen möchte.

[Sir Rufo]

Zitat:

Zitat von moelski (Beitrag 1063226)

Jede dieser Item_... Klassen ist abgeleitet von einer Basisklasse (Item_Root).
Diese Klasse hat eine Property:

Delphi-Quellcode:

property ITEM_SubItems : TObjectList        read FITEM_SubItems    write FITEM_SubItems;

Das bedeutet aber auch, dass Item_Root nicht die Hoheit über ITEM_SubItems hat.
Vor allem da kann ja alles drin stehen, auch eine Referenz, die es gar nicht mehr gibt ... sehr strange

Evtl. wäre das besser über Interfaces oder ein Visitor-Pattern zu lösen

Zitat:

Zitat von Neutral General (Beitrag 1063223)

Zitat:

Zitat von chaosben (Beitrag 1063221)

OT:

Zitat:

Zitat von Sir Rufo (Beitrag 1063211)

Und hierzu

Delphi-Quellcode:

for I := List.Count - 1 downto 0 do begin

sei folgendes gesagt:
Der Compiler entscheidet ob vorwärts oder rückwärts gezählt wird, somit kann auch dieses hier in die Hose gehen

Das ist doch ein Scherz, oder? Wenn nicht, würde ich das gern in einem neuen Thread besprechen.

Ist beides nicht ganz korrekt. Der Compiler zählt nur rückwärts, wenn es keinen Unterschied macht ob die Schleife vorwärts oder rückwärts läuft (weils schneller ist). In diesem Fall gibt es nichts zu befürchten. Die Schleifen würde immer rückwärts laufen.

Stimmt, so war das :stupid:

[jfheins]

Zitat:

Zitat von moelski (Beitrag 1063226)

Ob dieses Konstrukt nun der beste weg sei, das sei mal dahingestellt. Für mich erfüllt es seinen Zweck :)

Leider komme ich nicht drumrum einzelne Objecte in verschiedenen Listen einzufügen. Deshalb nutze ich dort dann OwnsObject = False.

Nur Sir Rufo hat schon Recht ... Das führt zu Problemen wenn man einen ganzen Projekt Tree (Ab Item_Project) entfernen möchte.

Du kannst aber alle Listen (rekursiv) durchlaufen und alle Objekte nochmal in eine "Masterliste" einfügen (duplikate ignorieren), dann die Listen freigeben und schließlich durch die Masterliste durchgehen und alle Objekte freigeben. (Du kannst natürlich auch die Masterliste immer "nebenher" aktuell halten)

Btw.: Punkt für Garbage-Collection :mrgreen:

[moelski]

Moin !

Zitat:

Vor allem da kann ja alles drin stehen, auch eine Referenz, die es gar nicht mehr gibt ...

Durchaus richtig.

Gibt es denn überhaupt die Möglichkeit zu Prüfen ob eine Referenz noch auf eine gültige Instanz verweist?
Ich habe schon NIL / Assigend probiert. Das führt aber nicht zum Erfolg.

Zitat:

Du kannst aber alle Listen (rekursiv) durchlaufen und alle Objekte nochmal in eine "Masterliste" einfügen (duplikate ignorieren), dann die Listen freigeben und schließlich durch die Masterliste durchgehen und alle Objekte freigeben.

Das würde gehen. Aber evtl. gehts ja auch einfacher ?

[jfheins]

Zitat:

Zitat von moelski (Beitrag 1063236)

Gibt es denn überhaupt die Möglichkeit zu Prüfen ob eine Referenz noch auf eine gültige Instanz verweist?
Ich habe schon NIL / Assigend probiert. Das führt aber nicht zum Erfolg.

Du könntest auch noch Interfaces verwenden. Die bringen eine Referenzzählung mit.

oder die Dirty-Variante: Du implementiert ein Boolean-Flag "valid" dass im Konstruktor auf true gesetzt wird. Im Destruktor wird es erst geprüft ob es false ist. Wenn ja => sofort abbrechen. Wenn nein: Auf false setzen und mit den normalen Tätigkeit fortfahren.
Das Vorgehen baut aber darauf, dass in der zwischenzeit keiner den Speicher überschreibt ^^

[stahli]

Zitat:

Zitat von moelski (Beitrag 1063236)

Gibt es denn überhaupt die Möglichkeit zu Prüfen ob eine Referenz noch auf eine gültige Instanz verweist?

Das wurde mal hier diskutiert.

[Sir Rufo]

Oder du sorgst dafür, dass die Objekte wissen, wo sie überall referenziert werden und dann selber dafür sorgen diese Referenzen zu entfernen.
Kleines Beispiel dafür ist hier mit einem Visitor gelöst.

Zur Vereinfachung habe ich alle möglichen Prüfungen herausgelassen (Ist Item schon SubItem beim hinzufügen oder ist Item überhaupt SubItem beim Entfernen)

Delphi-Quellcode:

unit uObjects;

interface

uses
  Classes, Contnrs;

type
  TMyItem = class
  private
    FSubItems : TObjectList;
    FAnchors : TObjectList;
    // Die Visitor-Routinen
    procedure AddedToItem( Item : TMyItem );
    procedure RemovedFromItem( Item : TMyItem );

  public
    property SubItems : TObjectList read FSubItems;
    property Anchors : TObjectList read FAnchors;
    // Hinzufügen und entfernen nur über diese Routinen
    procedure AddSubItem( Item : TMyItem );
    procedure RemSubItem( Item : TMyItem );

    constructor Create;
    destructor Destroy; override;
  end;

implementation

{ TMyItem }

procedure TMyItem.AddedToItem( Item : TMyItem );
  begin
    FAnchors.Add( Item );
  end;

procedure TMyItem.AddSubItem( Item : TMyItem );
  begin
    FSubItems.Add( Item );
    Item.AddedToItem( Self );
  end;

procedure TMyItem.RemovedFromItem( Item : TMyItem );
  begin
    FAnchors.Remove( Item );
  end;

procedure TMyItem.RemSubItem( Item : TMyItem );
  begin
    FSubItems.Remove( Item );
    Item.RemovedFromItem( Self );
  end;

constructor TMyItem.Create;
  begin
    inherited;
    FSubItems := TObjectList.Create;
    FAnchors := TObjectList.Create;
  end;

destructor TMyItem.Destroy;
  var
    obj : TObject;
  begin

    // Verbindungen lösen wo man SubItem ist
    while FAnchors.Count > 0 do
      begin
        obj := FAnchors[ 0 ];
        if obj is TMyItem then
          TMyItem( obj ).RemSubItem( Self );
      end;

    // Verbindungen zu den SubItems lösen
    while FSubItems.Count > 0 do
      begin
        obj := FSubItems[ 0 ];
        if obj is TMyItem then
          RemSubItem( TMyItem( obj ) );
      end;

    FSubItems.Free;
    FAnchors.Free;
    inherited;
  end;

end.

[stahli]

[etwas OT]
Aber eine Option im Compiler wäre schon schön. Lösbar wäre das sicher.
- Welchem Pointer wurde welche Speicheradresse zugewiesen?
- Welche Adresse wird freigegeben und welche Pointer müssen auf nil gesetzt werden?
(Bei Propertys müsste (sofern vorhanden die private Variable genilt werden.)
Ich kann mir schon viele Fälle denken, in denen das hilfreich wäre.
Der Programmierer müsste sich dann entscheiden, ob er diese Option (und die benötigte Zeit dafür) nutzen will.
Private Visitor-Lösungen funktionieren ja letztlich genau so, nur eben auf eigene Komponenten begrenzt.
[/etwas OT]