Lebensdauer einer Stringlist

[idefix2]

Beim Programmstart erzeuge ich im Formcreate des Hauptformulars eine lokale Stringlist, die ich einer Reihe von Dropdown-Boxen als Itemliste zuordne.
Die lokale Variable vom Typ TStringlist verschwindet natürlich beim Beenden von Formcreate.
Auf diese Art produziere ich allerdings vermutlich ein Speicherleck, das sich natürlich erst beim Beenden des Programms manifestiert - bis dahin wird die Stringlist von den Dropdown-Boxen ja gebraucht - und daher nichts wirklich Böses anrichten kann.

Würdet ihr die Variable extra in den private-Bereich der Form übersiedeln, um beim Programm Beenden die Stringlist wieder freizugeben? Wäre das für irgend etwas gut?

[Sir Rufo]

Keine deiner ComboBoxen braucht die nachher noch.

Du kannst die StringList beruhigt direkt in der Methode wieder freigeben.

[Dejan Vu]

Speicherlecks findet man zuverlässig mit Bordmitteln und/oder FastMM, zu dessen Verwendung ich dringend rate.

[Aviator]

Zitat von Dejan Vu:

Speicherlecks findet man zuverlässig mit Bordmitteln und/oder FastMM, zu dessen Verwendung ich dringend rate.

Er weiß doch woher sein Speicherleck kommt. Nur war seine Frage, wann er denn die StringList wieder freigeben kann. Da die Items aus der StringList wohl in seine ComboBoxen "kopiert" werden, braucht er die StringList nicht mehr und kann diese deshalb im FormCreate, wie von Sir Rufo bereits angemerkt, direkt wieder freigeben.

[idefix2]

Ah, danke. Das war mir nicht klar.
Ich war der Meinung, die verschiedenen Comboboxen verweisen dann nur auf die eine Stringlist. Dann ist es einfach.

Verstehe ich allerdings nicht ganz, weil die Zuweisung eines TObject doch normalerweise keine Kopie anlegt, dazu ist doch "assign" notwendig (das ich nicht verwendet habe, weil ich mir gedacht habe, einmal reicht, der Inhalt wird im ganzen Programmlauf nicht mehr geändert). Warum ist das in dem Fall anders?

[Sir Rufo]

Das siehst du, wenn du dir den Setter von TComboBox.Items anschaust.

Was finden wir da? Ein Assign

Und die Items sind sowieso keine TStringList , somit würde eine reine Zuweisung nicht funktionieren.

[idefix2]

Zitat von Sir Rufo:

Das siehst du, wenn du dir den Setter von TComboBox.Items anschaust.

Was finden wir da? Ein Assign

Ein assign im Setter, das ist fies...
Der Nachteil von OOP ist wohl, dass man sich auf nichts wirklich verlassen kann.

Zitat von Sir Rufo:

Und die Items sind sowieso keine TStringList , somit würde eine reine Zuweisung nicht funktionieren.

Aber TStringlist ist doch Nachkomme von TStrings, so eine Zuweisung muss doch ganz normal funktionieren. Es ist doch im Gegenteil so, dass TStrings eine virtuelle Klasse ist und direkt gar nicht instanziiert werden kann (soll).

[Jumpy]

Zitat von idefix2:

Es ist doch im Gegenteil so, dass TStrings eine virtuelle Klasse ist und direkt gar nicht instanziiert werden kann (soll).

Meinst du vielleicht abstrakte (statt virtuelle) Klasse? Das sind die, die man nicht direkt erstellen kann, sondern erst die Nachfahren.

[frankyboy1974]

Hallo,

es gibt in Delphi abstrakte Methoden (eine Methode die deklariert aber nicht implementiert ist). Daneben kann ich eine Methode als virtuell deklarieren (bzw. als dynamic, meint grundsätzlich das gleiche). Damit erreicht man dann polymorphes Verhalten, man deklariert in der Oberklasse eine virtuelle Methode (kann ggf. auch abstrakt sein), und in den verschiedenen Unterklassen überschreibt man dann die virtuelle Methode. Nun wird erst zur Laufzeit entschieden, wessen Methode tatsächlich ausgeführt wird (spätes Binden).

Eine Klasse die mindestens eine abstrakte Methode enthält, bezeichnet man dann gemeinhin als abstrakte Klasse. In Delphi kann man (anders als beispielsweise in Java), auch Instanzen von abstrakten Klassen erzeugen. Ruft man nun aber zur Laufzeit eine abstrakte Methode auf, erhält man eine entsprechende Fehlermeldung.

Ich wollte nur mal ein wenig klug sch.. Damit die Begrifflichkeiten, nicht ganz so durcheinander gewürfelt werden.

mfg

frank

[DeddyH]

Zitat von idefix2:

Ein assign im Setter, das ist fies...

Ich würde eher im Gegenteil behaupten, das ist mal nachgedacht, um Dangling Pointer durch unbedachte Zuweisung zu verhindern. Und wenn man sich nicht sicher ist (oder die Sourcen nicht hat), ruft man eben selbst Assign auf.

Delphi-Quellcode:

var
  MyStrings: TStringlist;
begin
  MyStrings := TStringlist.Create;
  try
    MyStrings.Add('Eins');
    MyStrings.Add('Zwei');
    MyStrings.Add('Drei');
    SomeComboBox.Items.Assign(MyStrings);
  finally
    MyStrings.Free;
  end;
end;