Zitat von
Robert_G:
Zitat von
r2c2:
3. In größeren Projekten(meinend nicht in meinen bisherigen) kann dies aber
IMHO sinnvoll sein
Mir fällt da einfach kein Fall ein, in dem man es mit einer Interface instanz nicht einfacher lösen könnte...
*an den Haaren herbeizieh* Wenn man viele Objekte erstellt und die vorher(d.h. nicht erst im Desructor der Containerklasse) freigeben will. Ich hab mich allerdings mit Interfaces noch zu wenig befasst, alsdass ich sagen könnte ob mans damit einfacher hinkriegt.
Zitat von
Robert_G:
Zitat von
r2c2:
Gibt es eigentlich eine sinnvolle Begründung dafür den destructor zu überladen? Warum sollte man das tun? Reicht ein Destructor nicht?
Man sollte es nicht.
TObject.Free ruft TObject.Destroy auf. Jeder Vorfahre/Nachfahre wird DIESEN Destructor überschrieben haben.
Und jeder, der die Klasse benutzt wird wohl auch Free oder den Destructor von TObject aufrufen um aufzuräumen.
Der Code in einem nicht überschriebenen Destructor wird also effektiv nie ausgeführt werden.
Deshalb gleich nochmal:
virtual &
override Jein, wenn man sich n eigenes Free bastelt vielleicht schon.
Das war aber auch gar nicht meine Frage. Man könnte doch theoretisch den destuctor overriden
und overloaden. Dann könnte man sich n eigenes Free basteln und bedingt die einzelnen Destruktoren aufrufen. Jetzt meine Frage: Macht das sinn? Und wenn ja: welchen?
mfg
Christian
P.S.: virtual und override sind mir durchaus bekannt.
