Objectlist rekursiv free?

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