Wo wird der Heap von Feldvariablen von Objekten freigegeben?

[QuickAndDirty]

TObject.Destroy ist ja nun mal ohne code
TObject.Free auch (wenn man nicht im ARC modus ist)
Also brauche ich Inherited Destroy in Nachfahren auch nicht aufrufen, oder?

Delphi-Quellcode:

unit test
interface 
uses System.types, classes, math, TypInfo, sysutils;
type
  TMYObject = class
  public
    owner:tobject;
    Number:Integer;  
    Destructor Destroy;override;
  end;
var MYObject:tMyObject;
implementation
Destructor TMYObject.destroy;
Begin
end;

initialize
  MYObject := tMyObject.create;
  MYObject.Owner := MyObject;
  MYObject.Number := 20000;
  MYObject.free;
end.

Wie weiß Delphi (oder der Speichermanager) dass Owner und Number auf dem Heap frei sind wenn MYObject.free keinen Code ausführt?

[Uwe Raabe]

Zitat von QuickAndDirty:

Also brauche ich Inherited Destroy in Nachfahren auch nicht aufrufen, oder?

Doch, musst du! Embarcadero wartet bloß darauf, das das jemand so macht, um bei der nächsten Version irgendeinen immens wichtigen Code dort auszuführen, der dein Programm dann crashen lässt, weil er dort nicht ausgeführt wird.

OK, Spaß beiseite. Man ruft immer (irgendjemand findet hier sicher noch eine Ausnahme) inherited Destroy auf ebenso wie inherited Create, weil man eben nicht von obigem Szenario betroffen sein möchte, falls es mal wirklich so kommt.

Zitat von QuickAndDirty:

Wie weiß Delphi das Owner und Number auf dem Heap frei sind wenn MYObject.free keinen Code ausführt?

Create und Destroy sind nur die Stellen, wo der Delphi-Entwickler eingreifen soll/kann, z.B. wenn Felder in der Klasse auf Instanzen zeigen, die ebenfalls freigegeben werden müssen. Die eigentliche Erzeugung und Freigabe der Instanzen und deren Inhalte erfolgt in NewInstance und FreeInstance, die vom Compiler implizit aufgerufen werden (z.B. _ClassCreate und _ClassDestroy, aber das ist ein ziemlich komplexes Thema und nicht in zwei Sätzen umfassend zu beschreiben). Das unterscheidet einen constructor/destructor eben von einer normalen (class-)method eines TObjects.

[himitsu]

Andersrum: Man kann auch einfach immer und überall inherited reinmachen, selbst wenn es noch nicht überschrieben ist.

[QuickAndDirty]

Zitat von himitsu:

Andersrum: Man kann auch einfach immer und überall inherited reinmachen, selbst wenn es noch nicht überschrieben ist.

aber warum? Meinst du jetzt nur destructor und constructor oder wirklich "überall" ?

[himitsu]

überall

[Uwe Raabe]

Zitat von QuickAndDirty:

aber warum?

Ich dachte, das hätte ich deutlich gemacht.

Zitat von QuickAndDirty:

Also wann wird _ClassDestroy aufgerufen? Es ist ne CompilerMagic sache nehme ich an so wie der RefCount bei ARC.
Wird es automatisch nach .Free eingefügt?

Genauer gesagt nach dem Destroy, weil das ein destructor ist. Das Free ist ja nur eine ganz normale Methode. Vor dem Destroy wird übrigens auch noch _BeforeDestruction aufgerufen. Diese Aufrufe sieht man nirgendwo im Quellcode, sondern der Compiler setzt sie automagisch ein.

Zitat von himitsu:

überall

Nein, nicht überall - zumindest nicht bedingungslos. So sollte man bei einem override von Assign nur dann das inherited aufrufen, wenn man weiß, dass die Parentklasse da noch was Sinnvolles macht. Leitet man direkt von TPersistent ab oder gibt es in der Hierarchie dazwischen kein Assign-override, dann sollte man inherited nur dann aufrufen, wenn man mit der Source nichts anfangen kann. Sinngemäß gilt das auch für AssignTo.

[himitsu]

Nja, gundsätzlich erstmal überall, außer explizit dort, es man wirklich den Vorfahren nicht ausführen will.

Letzteres macht man bewusst.
Und so kann man es aber auch nicht vergessen, wenn man es (erstmal) standardmäßig immer macht.

Bei vererbten Forms, macht der Formdesigner auch erstmal in alle von ihm erzeugte Events rein.

[QuickAndDirty]

Zitat von Uwe Raabe:

Zitat von QuickAndDirty:

Also brauche ich Inherited Destroy in Nachfahren auch nicht aufrufen, oder?

Doch, musst du! Embarcadero wartet bloß darauf, das das jemand so macht, um bei der nächsten Version irgendeinen immens wichtigen Code dort auszuführen, der dein Programm dann crashen lässt, weil er dort nicht ausgeführt wird.

OK, Spaß beiseite. Man ruft immer (irgendjemand findet hier sicher noch eine Ausnahme) inherited Destroy auf ebenso wie inherited Create, weil man eben nicht von obigem Szenario betroffen sein möchte, falls es mal wirklich so kommt.

Zitat von QuickAndDirty:

Wie weiß Delphi das Owner und Number auf dem Heap frei sind wenn MYObject.free keinen Code ausführt?

Create und Destroy sind nur die Stellen, wo der Delphi-Entwickler eingreifen soll/kann, z.B. wenn Felder in der Klasse auf Instanzen zeigen, die ebenfalls freigegeben werden müssen. Die eigentliche Erzeugung und Freigabe der Instanzen und deren Inhalte erfolgt in NewInstance und FreeInstance, die vom Compiler implizit aufgerufen werden (z.B. _ClassCreate und _ClassDestroy, aber das ist ein ziemlich komplexes Thema und nicht in zwei Sätzen umfassend zu beschreiben). Das unterscheidet einen constructor/destructor eben von einer normalen (class-)method eines TObjects.

Also wann wird _ClassDestroy aufgerufen? Es ist ne CompilerMagic sache nehme ich an so wie der RefCount bei ARC.
Wird es automatisch nach .Free eingefügt?