Wer und was ruft alles TList.Pack() auf (und warum?)

[Der schöne Günther]

Elementares Verhalten einer elementaren Klasse. Und ich finde nichts konkretes.

Folgendes: Ich dachte, ich sei schlau und füge einer TObjectList ab und an auch mal ein eine Nullreferenz hinzu: Add(nil) . Das Anfügen scheint allerdings immer einen Pack() -Befehl auszuführen: Die Nullzeiger werden hier wohl herausgeworfen. Dabei waren doch gerade die Teil meiner ausgefuchsten Überlegungen!

Das DocWiki spricht zu Pack() :

Zitat:

Löscht alle nil- (Delphi) oder NULL- (C++) Elemente aus dem Array Items.

Mit Pack werden innerhalb des Arrays Items alle Elemente, die keine nil- (Delphi) bzw. keine NULL- (C++) Zeiger sind, nach vorne gebracht. Dabei wird der Wert der Eigenschaft Count auf die Zahl der Elemente verringert, die tatsächlich verwendet werden. Die Methode Pack gibt allerdings den für die nil- (Delphi) bzw. NULL- (C++) Zeiger verwendeten Speicher nicht frei. Hierzu muss die Eigenschaft Capacity auf den neuen Wert von Count gesetzt werden.

In der Hilfe vermisse ich zu Add() jetzt den Hinweis, dass Pack() überhaupt aufgerufen wird. Insgesamt auch, welche Methoden noch auf ein Pack() zurückgreifen. Und ob ich das vielleicht auch abstellen kann.

Doch Ihr werdet mir sicher weiterhelfen können.

[sx2008]

Zitat von Der schöne Günther:

Ich dachte, ich sei schlau und füge einer TObjectList ab und an auch mal ein eine Nullreferenz hinzu

Schlauer wäre es das Null-Objekt-Pattern einzusetzen.

Nehmen wir mal an, bei den Objekte handle es sich um Spielfiguren, die sich selbst zeichnen können.

Delphi-Quellcode:

TGameObj = class(TObject)
public
  procedure Paint2Canvas(canvas:TCanvas);virtual; abstract;
end;

TNullGameObj = class(TGameObj)
public
  procedure Paint2Canvas(canvas:TCanvas);override;
end;

procedure TNullGameObj.Paint2Canvas(canvas:TCanvas);
begin
  // nichts tun
end;

Anstatt nil werden jetzt bei Bedarf Objekte der Klasse TNullGameObj eingefügt.

Das hat den Vorteil dass man später keine Fallunterscheidung benötigt und Null-Objekte genau gleich wie alle anderen Objekte behandeln kann.

[Uwe Raabe]

Zitat von Der schöne Günther:

In der Hilfe vermisse ich zu Add() jetzt den Hinweis, dass Pack() überhaupt aufgerufen wird.

Wird es auch gar nicht.

Edit: wir reden doch hier über System.Contnrs.TObjectList?

[Der schöne Günther]

Nein, die Objektliste ist parametrisiert und stammt somit aus System.Generics.Collections . Macht das einen Unterschied?

Noch einmal ein ganz einfaches Beispiel:

1. Liste anlegen: meineListe := TObjectList<TMeinObjekt>.Create(True);
2. meineListe.Add(nil);
3. Ablauf im Debugger für Add(nil) anschauen

Ich habe mal als vier Bilder angehängt, was man im Aufrufstack bzw. im Quelltext-Editor sieht. Ich verstehe es nicht.


Edit:
Bei Niklaus Wirths Lendenschurz, kann es sein, dass Pack() tatsächlich nie aufgerufen wird? Ich habe mich mit dem Delphi-Debugger noch nicht richtig anfreunden können, er scheint oft eine Zeile zu weit unten zu markieren. Wenn man auf das letzte Bild schaut - Meint der Debugger in Wirklichkeit die Notify-Methode? Das würde vollkommen Sinn machen.

[Uwe Raabe]

Prüf doch einfach, ob nach dem Add der Count auf 1 steht.

[Der schöne Günther]

Ja, es ist alles im grünen Bereich

Ich bin nur wieder aufgeschreckt, da mir der Debugger wieder "eine Funktion zu weit nach unten" gerutscht ist und behauptet hat, er würde gerade in meineListe.Pack() stecken, statt meineListe.Notify() .

Pack() wurde tatsächlich nie angefasst, so wie es sein sollte.

Vielen Dank für die Teilnahme

Und ja, eine eigene Nullinstanz wäre sicher besser, ich war bislang nur zu faul


Und für diese komische Debugger-Sache mache ich bei Gelegenheit (und Notwendigkeit) noch einmal ein neues Thema auf, das bringt mich wirklich durcheinander...