Objectlist rekursiv free?

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

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

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.

[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:
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 von moelski:

Jede dieser Item_... Klassen ist abgeleitet von einer Basisklasse (Item_Root).
Diese Klasse hat eine Property:
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 von Neutral General:

Zitat von chaosben:

OT:

Zitat von Sir Rufo:

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

[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 von moelski:

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

[chaosben]

OT:

Zitat von Sir Rufo:

Und hierzu 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 von chaosben:

OT:

Zitat von Sir Rufo:

Und hierzu 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.