Eltern haften für ihre Kinder (dynamisch erstellte Controls)

[Guido Eisenbeis]

In diesem Topic geht es um das Freigeben von zur Laufzeit dynamisch erstellter Controls. Sind die Eltern (Parent/Owner) für ihre Kinder (Child/Controls) verantwortlich?

Wird zum Beispiel ein TButton zur Laufzeit erstellt, so wird ihm unter anderem ein Owner zugewiesen.

Delphi-Quellcode:

MyButton := TButton.Create(self); // Owner zuweisen
MyButton.Parent := self;          // Parent zuweisen
...

In einigen Tutorials wird gesagt, man solle zur Laufzeit erstellte Controls selbst wieder freigeben.
Beispiel: Komponenten zur Laufzeit erstellen

Die OnlineHilfe sagt zum Thema Owner:

Zitat:

[Delphi] property Owner: TComponent read FOwner;

Beschreibung

Mit dieser Eigenschaft können Sie den Eigentümer einer Komponente ermitteln. Der Eigentümer ist für zwei Aufgaben zuständig:

Die untergeordnete Komponente wird bei der Freigabe des Eigentümers automatisch aus dem Speicher entfernt. Das bedeutet, dass alle Komponenten eines Formulars zusammen mit dem Formular freigegeben werden.

...

Standardmäßig ist ein Formular allen in ihm enthaltenen Komponenten übergeordnet. Dem Formular wiederum ist die Anwendung übergeordnet. Daher wird der Speicher für das Formular (und alle untergeordneten Komponenten) freigegeben, wenn die Anwendung geschlossen und deren Speicher freigegeben wird. Wird ein Formular in den Speicher geladen, lädt es alle in ihm enthaltenen Komponenten.

Der Eigentümer einer Komponente wird von dem Parameter bestimmt, der beim Erzeugen der Komponente an den Konstruktor übergeben wird. Bei Komponenten, die im Formular-Designer erzeugt werden, wird automatisch das Formular als Eigentümer (Owner) zugewiesen.

Ist das expliziete Freigeben von dynamisch erzeugten Controls notwendig oder nicht?
Anders gefragt: Werden dynamisch erzeugte Controls bei Programmende automatisch im Speicher freigegeben?


Guido.

[Elvis]

Eines der schönen Dinge an der VCL ist das standardisierte lifetime management.
Wenn der Owner freigeben wird, wird er wiederum alle seine Components[X] freigeben.

Zitat von Guido Eisenbeis:

Ist das expliziete Freigeben von dynamisch erzeugten Controls notwendig oder nicht?
Anders gefragt: Werden dynamisch erzeugte Controls bei Programmende automatisch im Speicher freigegeben?

Ja, aber willst du solange warten?
Wenn du dynamisch ein Panel anlegst, 5 Controls drauf wirfst und vllt noch eine Komponente, willst du sie nicht alle aus dem Speicher entfernen, wenn du sie nicht mehr brauchst?
Was in der UI dynamisch angelegt wird, wird höchstwahrscheinlich auch wieder entfernt.
Wenn du nun allen Controls und der Komponente das Panel als Owner verpasst, musst du nur noch dieses freigeben.
Oder wenn du nach MVC vorgehst, würdest du den Controller für dieses Panel/Frame als Komponente implementieren. So musst du nur ihn freigeben um auch die von ihm verwalteten Controls freizugeben.

btw: Du bist nicht zufällig der Bösewicht aus Darkwing Duck?

[SirThornberry]

Natürlich kannst du das Freigeben dem Owner überlassen. Nachteil ist das du dir das ganz schnell angewöhnst. Und dann erzeugst du irgendwann eine Stringliste (die nicht von TComponente abgeleitet ist) und vergisst diese freizugeben weil du es schon gewohnt bist das du nix mehr freigeben muss.
Es schadet nicht Componenten explizit freizugeben, es erhöht die Übersichtlichkeit wenn man nach einem Speicherleck sucht.

[Guido Eisenbeis]

Hallo Jens.

Zitat von SirThornberry:

Natürlich kannst du das Freigeben dem Owner überlassen.

Das bestätigt meine eigene Ansicht.

Zitat von SirThornberry:

Nachteil ist das du dir das ganz schnell angewöhnst. Und dann erzeugst du irgendwann eine Stringliste (die nicht von TComponente abgeleitet ist) und vergisst diese freizugeben weil du es schon gewohnt bist das du nix mehr freigeben muss.

Dem stimme ich zu. Angefangen zu progrmmieren habe ich mit Scriptsprachen wie zum Beispiel AutoIt. Dann war VB ein weiterer Meilenstein. Von VB war ich es gewohnt, mich um vieles nicht selbst kümmern zu müssen. Vor etwa zwei Jahren habe ich mit C++ angefangen (Umschulung). Dort muss man sich um ALLES selbst kümmern. Will man in C++ ein "Hallo Welt" auf dem Bildschirm ausgeben, muss man sich vorher erst einen Bildschirm programmieren! (... und natürlich einen Computer, eine Tastatur, einen Schreibtisch, ...)

Delphi nimmt einem zwar vieles an Arbeit ab, aber dennoch ist der Programmierer für sauberen Code verantwortlich.

Zitat von SirThornberry:

Es schadet nicht Componenten explizit freizugeben, es erhöht die Übersichtlichkeit wenn man nach einem Speicherleck sucht.

Auch hier "zustimm". Die Übersichtlichkeit ist mir wichtig! Ich verwende möglichst sprechende Namen bei Routinen, Variablen usw. Auch schreibe ich lieber mal einen Kommentar zu viel als zu wenig.

Vielen Dank für den Beitrag. Weiter Infos/Hintergründe sind willkommen, gleich ob jemand wiederspricht oder zustimmt.

Gruß,
Guido.

[Guido Eisenbeis]

Hallo Robert.

Sorry, ich war irgendwie blind und hab doch glatt deinen Beitrag übersehen.

Zitat von Elvis:

Eines der schönen Dinge an der VCL ist das standardisierte lifetime management.
Wenn der Owner freigeben wird, wird er wiederum alle seine Components[X] freigeben.

Eine weiter Bestätigung meiner Ansicht und dafür, dass Delphi "intelligent" ist.

Zitat von Elvis:

Zitat von Guido Eisenbeis:

Ist das expliziete Freigeben von dynamisch erzeugten Controls notwendig oder nicht?
Anders gefragt: Werden dynamisch erzeugte Controls bei Programmende automatisch im Speicher freigegeben?

Ja, aber willst du solange warten?

Yes, Sir! Bei Controls ist es bei mir meistens so, dass ich diese bis zum Beenden der Anwendung brauche.

Zitat von Elvis:

Wenn du dynamisch ein Panel anlegst, 5 Controls drauf wirfst und vllt noch eine Komponente, willst du sie nicht alle aus dem Speicher entfernen, wenn du sie nicht mehr brauchst?

Siehe oben.

Zitat von Elvis:

Was in der UI dynamisch angelegt wird, wird höchstwahrscheinlich auch wieder entfernt.
Wenn du nun allen Controls und der Komponente das Panel als Owner verpasst, musst du nur noch dieses freigeben.
Oder wenn du nach MVC vorgehst, würdest du den Controller für dieses Panel/Frame als Komponente implementieren. So musst du nur ihn freigeben um auch die von ihm verwalteten Controls freizugeben.

Ich hoffe, dass ich so ungefähr verstanden zu habe, was du beschreibst. (Was ist UI und was MVC?)

Den Gedanken finde ich interessant, dass man (wenn möglich) dynamisch erzeugte Controls in ein Panel setzt und dann nur dieses Panel freigeben muss!

Zitat von Elvis:

btw: Du bist nicht zufällig der Bösewicht aus Darkwing Duck?

Aber nur, wenn du Quack bist! (Verdammt, jetzt ist meine Tarnung aufgeflogen!)

PS: Habe gerade gesehen, dass du kurz vor deinem Tausendsten Beitrag bist! (998, falls du nicht inzwischen weiter geschrieben hast.) Wenn der Zähler umspringt, wird gefeiert!


Gruß,
Guido.

Edit: MVC habe ich herausgefunden -> Model-View-Controller

[Hansa]

Wende doch den alten Stringgrid-Objects-Trick sinngemäß an. Beim Erzeugen Variable hochzählen und beim Destroy usw. das ganze wieder runterzählen. Ist die Zahl am Ende anders als am Anfang, dann kann während der Laufzeit des Programmes irgendwas schiefgehen. Wichtig wäre da noch, die Sichtbarkeit möglichst gering zu halten.

[cruiser]

@Guido: Und UI steht schlicht für User Interface

[Elvis]

Zitat von Guido Eisenbeis:

Hallo Robert.
Sorry, ich war irgendwie blind und hab doch glatt deinen Beitrag übersehen.

Hehe, hattest dir um kurz vor 12 wohl 'ne Tomatenmaske auf deine geschwollenen Augen gelegt?Tomaten auf den Augen!

Zitat:

Zitat von Elvis:

]Ja, aber willst du solange warten?

Yes, Sir! Bei Controls ist es bei mir meistens so, dass ich diese bis zum Beenden der Anwendung brauche.

Nicht so hastig, du kannst dir so einen wahren Wartungsalptraum einhandeln.
Gehe immer davon aus, dass du etwas einfach wieder entladen/freigeben können musst.
Früher oder später wirst du es bei einigen Dingsens müssen.

Zitat:

Den Gedanken finde ich interessant, dass man (wenn möglich) dynamisch erzeugte Controls in ein Panel setzt und dann nur dieses Panel freigeben muss!

Hier sind wir wieder bei Übersichtlichkeit, die viele gerne mit masochistischem, verbosem "zu Fuss gehen" verwechseln.

Wenn du dynamisch einen Graph von Komponenten erzeugst, könntest du das eigentlich auch so machen:

Delphi-Quellcode:

var
  kompo1 : TKompo1;
  kompo2 : TKompo2;
  kompo3 : TKompo3;
begin
  kompo1 := TKompo1.Create(nil);
  try
    kompo2 := TKompo2.Create(kompo1);
    kompo3 := TKompo3.Create(kompo1);
    ...
  finally
    kompo1.Free();  
  end;

Da der Owner die Lebenszeit seiner Kinderchens verwaltet, bringt er sie einfach um, wenn er selbst sterben muss. Ergo: nur ein hässlicher try-finally-Block notwendig.

Zitat:

Zitat von Elvis:

btw: Du bist nicht zufällig der Bösewicht aus Darkwing Duck?

Aber nur, wenn du Quack bist! (Verdammt, jetzt ist meine Tarnung aufgeflogen!)

Zitat:

PS: Habe gerade gesehen, dass du kurz vor deinem Tausendsten Beitrag bist! (998, falls du nicht inzwischen weiter geschrieben hast.) Wenn der Zähler umspringt, wird gefeiert!

Hehe, ich war nicht immer "Elvis". Habe also mehr Beiträge. Der Zähler ist mir aber ziemlich Bohne.

[Guido Eisenbeis]

@Hansa

Ey, ä Saabregga!

Zitat von Hansa:

... Beim Erzeugen Variable hochzählen und beim Destroy usw. das ganze wieder runterzählen. Ist die Zahl am Ende anders als am Anfang, ...

Das halte ich für sinnvoll. Wird unter meinen "nützlichen Tipps" gespeichert.

Was meinst du mit "Sichtbarkeit möglichst gering halten" ?


@Ronny

Zitat von cruiser:

@Guido: Und UI steht schlicht für User Interface

Das dachte ich mir schon. Ich hielt die Antwort aber für "zu einfach".


@Robert

Beitrag übersehen: Ich habe jetzt auch bemerkt, dass die "Forumsdynamik" ihren Teil dazu beigetragen hat. Auch wenn mehrere Antworten auf einen Beitrag geschrieben werden, wird nur eine Mitteilung vom Forum geschickt (bis man das Thema wieder besucht). Ein Klick im Mail-Client scrollt dann die Topic-Seite schön bis zum letzten Beitrag ... und schwups ist der oberdrüber unsichtbar.

Zitat von Elvis:

Hier sind wir wieder bei Übersichtlichkeit, die viele gerne mit masochistischem, verbosem "zu Fuss gehen" verwechseln.

Auch *zustimm*. Mag sein, dass man dann mehr Schreibarbeit hat. Die Übersichtlichkeit und die Wartbarkeit werden dadurch aber erhöht und man spart sich an anderer Stelle viel Arbeit und Sucherei ein.

Zitat von Elvis:

Wenn du dynamisch einen Graph von Komponenten erzeugst, könntest du das eigentlich auch so machen:

Delphi-Quellcode:

...
  kompo1 := TKompo1.Create(nil);
  try
    kompo2 := TKompo2.Create(kompo1);
    kompo3 := TKompo3.Create(kompo1);
    ...
  finally
    kompo1.Free();  
  end;

Das sieht doch nach der *Panel-und-dann-alles-rein-setz"-Methode aus!? Wie gesagt, halte ich für sinnvoll -> *unter-"nützlichen Tipps"-speicher*.

Zitat von Elvis:

Da der Owner die Lebenszeit seiner Kinderchens verwaltet, bringt er sie einfach um, wenn er selbst sterben muss.

*lol*

So, genug geschwatzt! Ich muss jetzt Schluss machen, Kiki ruft!

Danke an alle!

Guido