Destruktor überladen

[Majortomster]

Aber der Aufruf des überschriebenen Destruktors führt ins Chaos (da dort auch Free für klasseninterne Komponenten eingesetzt wird).

[phlux]

Eigentlich logisch das alles was das zu free-ende Objekt als Parent hat mit ge-free-ed wird oder habe ich die aussage falsch aufgenommen?

[Majortomster]

Ja das ist logisch - aber mittlerweile entgeht mir total der Sinn von Free.
Ich hatte das so verstanden, dass dies eine SICHERE Art ist, den Destruktor aufzurufen (oder eben nicht, wenn die Referenz nil ist).
Aber was ist diese Methode wert, wenn sie selbst in Bedrängnis kommt (Exception mit Speicherlesefehler), wenn sie zwei Mal in Folge aufgerufen wird..?
In einem äußerst komplexen Programm mit sehr vielen verschiedenen Objekten die viel Speicher fressen, ist man da echt aufgeschmissen... oder sehe ich das falsch?

(jedenfalls klappt es jetzt super mit FreeAndNil(objekt) - danke )

T

[r2c2]

Zitat von Majortomster:

Ja das ist logisch - aber mittlerweile entgeht mir total der Sinn von Free.
Ich hatte das so verstanden, dass dies eine SICHERE Art ist, den Destruktor aufzurufen (oder eben nicht, wenn die Referenz nil ist).
Aber was ist diese Methode wert, wenn sie selbst in Bedrängnis kommt (Exception mit Speicherlesefehler), wenn sie zwei Mal in Folge aufgerufen wird..?
In einem äußerst komplexen Programm mit sehr vielen verschiedenen Objekten die viel Speicher fressen, ist man da echt aufgeschmissen... oder sehe ich das falsch?

(jedenfalls klappt es jetzt super mit FreeAndNil(objekt) - danke )

T

Genau für solche "äußerst komplexen Programme mit sehr vielen verschiedenen Objekten die viel Speicher fressen" ist FreeAndNil gedacht. Dann kann nämlich nix mehr passieren.
Free kann man dann immer noch "gebrauchen", z.B. für lokale Objekte; da bringt das "nillen" nix, wenn die Procedure eh zu ende ist.

mfg

Christian

[Robert_G]

Wenn du deinen Destructor mit overload deklarierst ist es eine ANDERE Methode als der Destructor des Vorgängers und damit wiederum ein anderer als der von TObject!!!
Free wird TObject.Destroy aufrufen. Nur wenn du es ÜBERSCHREIBST wird dann dein Code ausgeführt.
Und ja, das ist ein bequemer und sicherer Weg Speicher freizugeben. Du solltest dich einfach noch ein bisschen in OO Vorgehensweisen belesen.
Virtual methods sind IMHO eines der wichtigsten Prinzipien von objektorientierter Programmierung, das sollte man als Delphisti schon wissen.

@r2c2
Habe ich früher auch oft gemacht.
Mittlerweile wirkt FreeAndNil für mich wie irgendein Artefakt, dass irgendwie nicht so richtig in den Code passt.
Wie oft hat man schon eine Referenz, die man auf nil setzen will, die kein Interface ist?

[r2c2]

Zitat von Robert_G:

@r2c2
Habe ich früher auch oft gemacht.
Mittlerweile wirkt FreeAndNil für mich wie irgendein Artefakt, dass irgendwie nicht so richtig in den Code passt.
Wie oft hat man schon eine Referenz, die man auf nil setzen will, die kein Interface ist?

FreeAndNil Artefakt?
Zugegeben ich benutze FreeAndNil kaum, aber das hängt meiner Meinung daran, dass ich noch nicht so lange OO programmiere. Bisher hab ich fast nur lokale Objekte benutzt und ansonsten eine Art "Matster-Objekt" erstellt, das alle anderen Objekte erzeugt un im Destructor wieder freigibt. Ich kann mir aber duchaus vorstellen, dass in größeren Projekten FreeAndNil sinnvoll sein kann. Oder?

mfg

Christian

[Robert_G]

Zitat von r2c2:

FreeAndNil Artefakt?
Zugegeben ich benutze FreeAndNil kaum, aber das hängt meiner Meinung daran, dass ich noch nicht so lange OO programmiere. Bisher hab ich fast nur lokale Objekte benutzt und ansonsten eine Art "Matster-Objekt" erstellt, das alle anderen Objekte erzeugt un im Destructor wieder freigibt.

Dann ist der Container ja auch weg. Warum sollte man also extra einen Zeiger auf nil setzen, wenn der einzige, der den Zeiger benutzt auch schon im Sterben liegt?
Free ist eine Methode, FreeAndNil ist eine lose Funktion, vllt liegt es daran, dass es mir irgendwie komisch und fehl am Platze vorkommt.

[r2c2]

@Robert_G

Zitat von Robert_G:

Dann ist der Container ja auch weg. Warum sollte man also extra einen Zeiger auf nil setzen, wenn der einzige, der den Zeiger benutzt auch schon im Sterben liegt?

Ich glaub du hast meinen Post nicht ganz verstenden. Les ihn dir am Besten nochmal durch:

Zitat von r2c2:

FreeAndNil Artefakt?
Zugegeben ich benutze FreeAndNil kaum, aber das hängt meiner Meinung daran, dass ich noch nicht so lange OO programmiere. Bisher hab ich fast nur lokale Objekte benutzt und ansonsten eine Art "Matster-Objekt" erstellt, das alle anderen Objekte erzeugt un im Destructor wieder freigibt. Ich kann mir aber duchaus vorstellen, dass in größeren Projekten FreeAndNil sinnvoll sein kann.

Letzterer Satz bedeutet:
1. Ich benutze FreeAnd Nil kaum
2. Das war in meinen beschriebenen 2 Fällen auch nicht notwendig
3. In größeren Projekten(meinend nicht in meinen bisherigen) kann dies aber IMHO sinnvoll sein

Zitat von Robert_G:

Free ist eine Methode, FreeAndNil ist eine lose Funktion, vllt liegt es daran, dass es mir irgendwie komisch und fehl am Platze vorkommt.

Ähm, keine Ahnung, du musst schon selbst wissen, warum dir was komisch vorkommt, hört sich für mich aber logisch an.

@All
Gibt es eigentlich eine sinnvolle Begründung dafür den destructor zu überladen? Warum sollte man das tun? Reicht ein Destructor nicht?

mfg

Christain

[Robert_G]

Zitat von r2c2:

@Robert_G Ich glaub du hast meinen Post nicht ganz verstenden. Les ihn dir am Besten nochmal durch:

Hmmm.... den habe ich wohl etwas falsch verstanden. Sehe deshalb meinen beitrag als Bestätigung für die Punkte 1 & 2.
Nur denn verstehe ich nicht ganz:

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...

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

[r2c2]

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.