TObjectList und Delete

[Popov]

Nur eine kleine Frage. TObjectList ist ja von TList abgeleitet. So weit, so gut. Mal von den paar kleinen Unterschieden abgesehen enthält TObjectList zusätzlich die Eigenschaft OwnsObjects. Soweit ich TList verstanden (ohne mich mit dem Code auseinander gesetzt zu haben) kümmert man sich manuell um die Freigabe der Objekte. Ist bei TObjectList OwnsObjects True, wird das Objekt automatisch freigegeben. So steht es zumindest in der OH. Dort steht: "Bei Aufruf von Delete oder Remove wird das Objekt aus der Liste entfernt und das gelöschte Objekt freigegeben". Da TList also die Eigenschaft nicht besitzt, muß man sich laut OH manuell um die Freigebe der Objekte kümmern, bei TObjectList geschied das automatisch (bei True).

Nun, das schient der große Unterschied hier zwischen den beiden Remove zu sein. Kommen wir nun zu Delete. Obwohl, im Gegensatz zu Remove, in der OH Delete unter 'Abgeleitet von TList' steht, scheint OwnsObjects trotzdem Einfluß drauf zu haben. Unter Delete steht: "Hinweis: Der für das Element reservierte Speicher wird von Delete nicht freigegeben. Hierzu muss die Eigenschaft Capacity neu gesetzt werden.".

Also was nun? Entweder ich verstehe die OH nicht oder den Sinn des Ganzen.

[Sir Rufo]

Damit ist einzig und allein der Speicher für die Referenz in der Liste gemeint und nicht das referenzierte Objekt ;)

Hat also nix mit freigeben oder den Objekten zu tun

[Popov]

Auf was beziehst du dich? Auf die Texte bezüglich Delete oder Freigabe der Objekte bei Remove? Denn Remove gibt das Objekt laut OH frei, genauso wie eigentlich auch Delete. Bei Remove steht: "Die Methode Remove löscht das angegebene Objekt aus der Liste und gibt das Objekt frei (falls OwnsObjects auf true gesetzt ist)". Da in der OH bei OwnsObjects ebenfalls steht: "Bei Aufruf von Delete oder Remove wird das Objekt aus der Liste entfernt..." so weit, so gut "...und das gelöschte Objekt freigegeben".

[Bummi]

Die Objekte werden freigeben, die "Arraygröße" der Liste als solche wird nicht verkleinert, d.h. hinter dem Zeiger auf das letzte Element bleibt noch Speicher alloziert der auch zwischendurch freigegeben werden könnte.

[sx2008]

Entweder man studiert den Sourcecode von

Delphi-Quellcode:

TObjectList.Delete

und

Delphi-Quellcode:

TObjectList.Remove

oder man schreibt ein kleines Testprogramm:

Delphi-Quellcode:

type
  TTestObj = class(TObject)
  private
    FInfo : string;
  public
    constructor Create(const Info:string);
    destructor Destroy;override;
  end;

constructor TTestObj.Create(const Info:string);
begin
  inherited Create;
  FInfo := Info;
  ShowMessageFmt('%s erzeugt', [Info]);
end;


destructor TTestObj.Destroy;override;
begin
  ShowMessageFmt('%s destroyed', [FInfo]);
  inherited;
end;

var
  olist : TObjectList;
begin
  olist := TObjectList.create({OwnsObjects=}True);
  olist.Add(TTestObj.Create('Object A');
  olist.Delete(0);
  olist.Add(TTestObj.Create('Object B');
  olist.Remove(0);
  ShowMessage('vor [TObjectList].Free...');
  olist.Free;

[Popov]

Ok, nur damit ich das jetzt richtig verstanden habe: bei dem Hinweis zu Delete geht es dadrum, dass Delete zwar den Count, aber nicht Capacity reduziert. Hier gibt Delete das Objekt frei (bei OwnsObjects True) und den Zeiger auf das Objekt. Gelegentlich, es ist aber kein Muss, kann man Capacity an Count angleichen.

Dieses Angleichen ist aber bei Remove und Clear nicht nötig? Steht zumindest nicht so in der OH. Obwohl Remove fast das gleiche wie Delete ist.

[Bummi]

@sx2008

das olist.Remove(0);
statt olist.Remove(olist[0]);
könnte zu einer verstärkten Verwirrung führen....

Delphi-Quellcode:

  olist := TObjectList.create({OwnsObjects=}True);
  olist.Add(TTestObj.Create('Object A'));
  olist.Add(TTestObj.Create('Object B'));
  olist.Add(TTestObj.Create('Object C'));
  olist.Delete(0);
  olist.Remove(olist[0]);
  ShowMessage('vor [TObjectList].Free...');
  olist.Free;

[Popov]

@sx2008

Ich kenne TObjectList, ich habe nur die OH nicht in allen Einzelpunkten verstanden. Sicher, man kann die Code studieren, mir geht es in erste Linie aber nur um Bestätigung oder Richtigstellung meiner Annahmen. Und Tests habe ich auch schon durchgeführt. Zwar nicht jetzt, sondern schon vor langer Zeit, aber gemacht. Mir ist nur der Unterschied zwischen Delete und Remove im Speziellem nicht klar. Aus dem Code werde ich auch nicht besonders schlau. Da ist kaum unterschied, aber bei dem einem steht das, bei dem anderen das. (Edit: bezogen auf die OH)

Und auf deine letzten Hinweis: ich kenne den Unterschied zwischen Remove und Delete. Das eine über das Objekt, das andere über die Indexnummer. Das ist aber nicht mein Anliegen.

[stahli]

Man darf aber nicht leichtfertig annehmen, dass Objekte, die von außen frei gegeben werden, auch automatisch aus der Liste entfernt werden (davon war ich Anfangs mal ausgegangen).
Explizit freigegebene Objekte bleiben somit als ungültiger Pointer in der Liste.

Extract entfernt übrigens ein Objekt, ohne es zu zerstören.

[Sir Rufo]

Zitat:

Zitat von Popov (Beitrag 1189270)

Auf was beziehst du dich? Auf die Texte bezüglich Delete oder Freigabe der Objekte bei Remove? Denn Remove gibt das Objekt laut OH frei, genauso wie eigentlich auch Delete. Bei Remove steht: "Die Methode Remove löscht das angegebene Objekt aus der Liste und gibt das Objekt frei (falls OwnsObjects auf true gesetzt ist)". Da in der OH bei OwnsObjects ebenfalls steht: "Bei Aufruf von Delete oder Remove wird das Objekt aus der Liste entfernt..." so weit, so gut "...und das gelöschte Objekt freigegeben".

Deine konkrete Frage war:

Zitat:

Zitat von Popov (Beitrag 1189268)

Also was nun? Entweder ich verstehe die OH nicht oder den Sinn des Ganzen.

diese bezog sich auf:

Zitat:

Zitat von Popov (Beitrag 1189268)

Kommen wir nun zu Delete. Obwohl, im Gegensatz zu Remove, in der OH Delete unter 'Abgeleitet von TList' steht, scheint OwnsObjects trotzdem Einfluß drauf zu haben. Unter Delete steht: "Hinweis: Der für das Element reservierte Speicher wird von Delete nicht freigegeben. Hierzu muss die Eigenschaft Capacity neu gesetzt werden.".

Und genau darauf habe ich geantwortet ;)

Wenn in der OH steht 'Abgeleitet von TList' dann bezieht sich das zu 100% auf TList und die Nachfolger, allerdings kann in den Nachfolgern noch etwas darüber hinaus passieren (konkret bei der TObjectList eben, dass bei OwnsObjects auch das enthaltene Object aus dem Speicher entfernt wird.

Der Text der OH kann also nur auf das TList-Verhalten bezogen werden (was die TObjectList auch erbt) und konkret ist eben damit der Speicherplatz für die Objekt-Referenzen gemeint. Der passende Hinweis ist hierfür Capacity.

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1189284)

Man darf aber nicht leichtfertig annehmen, dass Objekte, die von außen frei gegeben werden, auch automatisch aus der Liste entfernt werden (davon war ich Anfangs mal ausgegangen).
Explizit freigegebene Objekte bleiben somit als ungültiger Pointer in der Liste.

Extract entfernt übrigens ein Objekt, ohne es zu zerstören.

Wenn man es mal übersetzt, dann wird es auch klarer:

Delete - Löschen
Remove - Entfernen
Extract - Herausnehmen

Wenn es also ein Konstrukt gibt, das die Hoheit über die Verwaltung der beinhaltenden Objekte innehat, dann würde es mich stark verwundern, wenn ich da etwas "herausnehme" und das Objekt zerstört ist. Bei Remove und Delete erwarte ich hingegen, dass es zerstört wird.

[Popov]

@Sir Rufo

Du hast natürlich Recht, aber... (schon wieder; wird langsam zu einem Insiderwitz)

Zitat:

Wenn in der OH steht 'Abgeleitet von TList' dann bezieht sich das zu 100% auf TList und die Nachfolger, allerdings kann in den Nachfolgern noch etwas darüber hinaus passieren (konkret bei der TObjectList eben, dass bei OwnsObjects auch das enthaltene Object aus dem Speicher entfernt wird.

Der Text der OH kann also nur auf das TList-Verhalten bezogen werden (was die TObjectList auch erbt) und konkret ist eben damit der Speicherplatz für die Objekt-Referenzen gemeint. Der passende Hinweis ist hierfür Capacity.

Nur der Vollständigkeitshalber: Remove ist abgeleitet, Delete ist geerbt. Remove ist eine Methode von TObjectList, Delete von TList, nur geerbt. Trotzdem hat OwnsObjects Einfluss auf Delete, bzw. ändert diese. Es liegt an mir, aber ich verstehe nicht wieso OwnsObjects Einfluss auf Delete hat. Nicht dass Remove irgendwie besonders erweitert worden wäre, aber wieso ändern sich hier die Eigenschaften und wieso ist es bei Remove nicht nötig Capacity zu korrigieren?

Das sind alles unwichtige Fragen, ich könnte alles akzeptieren, aber es erleichtert das Verständnis.

[Sir Rufo]

1. Das Entfernen der Objekt-Instanzen (Free) erfolgt weder in der Methode Delete, noch in der Methode Remove, sondern in der Methode Notify, so wie das in der OH auch vermerkt ist für TList:
   
   Zitat:

   Zitat von System.Classes.TList.Delete

   Das Objekt kann freigegeben werden, indem die Methode Notify überschrieben wird

   Und genau das hat man bei der TObjectList so gemacht, man hat sich an die eigene Empfehlung gehalten
2. Bei Remove wird in der OH (ja, ist wohl suboptimal) nicht mitgeteilt, dass das wirkliche Entfernen durch den impliziten Aufruf von Delete erfolgt. In der Methode Remove wird nur über das Item der Index ermittelt und damit die Methode Delete aufgerufen.
   Damit gelten für Remove die gleichen Regeln wie für Delete ;)

Genau für solche Momente (wo die OH Fragen offen lässt) lohnt sich eigentlich immer ein Blick in die Quellen:

Delphi-Quellcode:

procedure TList.Notify(Ptr: Pointer; Action: TListNotification);
begin
end;

procedure TObjectList.Notify(Ptr: Pointer; Action: TListNotification);
begin
{$IFNDEF AUTOREFCOUNT}
  if (Action = lnDeleted) and OwnsObjects then
    TObject(Ptr).Free;
{$ENDIF !AUTOREFCOUNT}
  inherited Notify(Ptr, Action);
end;

[Popov]

Danke, wollte gerade schreiben, dass laut dem Beispiel Remove Capacity auch nicht reduziert.

Delphi-Quellcode:

var
  ol: TObjectList;
  icon: TIcon;
  i: Integer;
begin
  ol := TObjectList.Create;

  for i := 1 to 5 do
  begin
    icon := TIcon.Create;
    ol.Add(Icon);
  end;
  ShowMessage(Format('Count: %d, Capacity: %d', [ol.Count, ol.Capacity]));

  for i := 1 to 5 do ol.Remove(ol.Items[0]);
  {for i := 1 to 5 do ol.Delete(0);}
  ShowMessage(Format('Count: %d, Capacity: %d', [ol.Count, ol.Capacity]));

  ol.Free;
end;

Somit wäre der Punkt bestätigt.

Das mit Notify gucke ich mir jetzt mal an. Ich dachte mir zwar etwas in die Richtung, aber...

[Sir Rufo]

Zitat:

Zitat von Popov (Beitrag 1189294)

Danke, wollte gerade schreiben, dass laut dem Beispiel Remove Capacity auch nicht reduziert.

Somit wäre der Punkt bestätigt.

Öh, ein Klick und Blick hätte das auch verraten:

Delphi-Quellcode:

function TList.Remove(Item: Pointer): Integer;
begin
  Result := RemoveItem(Item, TList.TDirection.FromBeginning);
end;

function TList.RemoveItem(Item: Pointer; Direction: TDirection): Integer;
begin
  Result := IndexOfItem(Item, Direction);
  if Result >= 0 then
    Delete(Result); // <-- ja, da isses ja
end;

[Popov]

Nun ja, ich, dem Kaiser treu und obrigkeitsgläubig, suche zuerst den Fehler bei mir. Die von dir geposteten Code-Zeilen habe ich natürlich auch gesehen, ging aber zuerst davon aus etwas übersehen zu haben (passiert ja ständig bei mir). Ich hab oben ja auch geschrieben, dass Remove fast wie Delete ist, nur in grün. Ich brauche immer die Bestätigung, ob durch Beispiel oder von jemand anders.

Dein Hinweis zu Notify scheint in der aktuellen Hilfe zu TList.Delete zu stehen, in der alten steht der Hinweis nicht. Dafür steht in der neuen Hilfe nicht, dass Capacity evtl. neu gesetzt werden sollte, vorausgesetzt es ist wichtig (soll ja sowieso immer etwas größer sein und wie ich gerade bemerkt habe schafft Add an der Grenze immer ein neues Puffer von 4).

Was Notify im Code angeht, so habe ich es auch gesehen, wohl aber nicht richtig verstanden.

[Sir Rufo]

Die Eigenschaft Capacity kann man selber setzen z.B. um die Performance zu verbessern (wenn ich weiß, dass ich gleich 1000 Einträge da rein puste, dann kann ich die Größe ja auch schon mal festlegen) oder für die Speicheroptimierung (z.B. 800 Einträge fliegen wieder raus und werden erstmal nicht benötigt, dann wieder runter mit der Capacity)

Ansonsten läuft es aber auch, wenn man die Liste alles selber machen lässt ;)

[Popov]

Nun ja, ich gebe zu Capacity zwar zu kennen (gibt es ja auch in anderen Listen) nur habe ich mich noch nicht näher damit beschäftigt, bzw. genutzt.