Hallo,

diese Frage stelle ich im Allgemeinen, weil sie eher Delphi bzw Klassen betrifft.
Übrigens hab ich es mit den Klassen auch noch immer nicht wirklich so drauf.. also wenn ich was grundsätzlich falsch mache, einfach sagen..

So nun zum Problem:

Ich hab ne Klasse gebaut, die ihrerseits 2 objekte einer anderen Klasse erstellt.

So:



soweit so nett, jetzt pappe ich die Instanzen von TMyMeasure in eine TObjectList mit .ownsobjects, weil ich gelesen habe das dann die TObjectlist bei der Freigabe sich um die Freigabe seiner Objecte kümmert.
Tut sie auch, nur nicht für die Kinder der Objekte... also generiert ein MyObjectList.free ein Speicherleck von jeweils 2x TMyPoints.
Ich hab dann versucht einen destructor für TMyMeasure zu schreiben, der aber scheinbar nie aufgerufen wird..




im Ergebnis hab ich jetzt die Speicherlecks nur wegbekommen indem ich bei ONClose meiner Anwendung durch die Liste renne und für alle Objekte FP1 und FP2 free setze.


Jetzt die eigentlichen Fragen:

1.) Wieso wird mein destruktor nicht aufgerufen?
2.) Gibts da nichts einfacheres / besseres, mache ich eventuell grundsätzlich was verkehrt?

Danke schonmal

Ich vermute, du musst bei der Methode Destroy noch die Direktive "override" anhängen, also so:

TMyObject = class
destructor Destroy; override;
end;

Kommt bei dir keine Warnung, die iwas von Destroy aussagt?

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Und bitte auch noch ein inherit, damit die Vorgänger auch ihre Speicherbereiche räumen können.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

In der Tat, jetzt wo du es sagst...


(ich habe das letzte Nacht auch schon gesehen, konnte mir aber keinen Reim drauf machen)

Kaum schreibt man das override hintendran, wird der Destruktor wohl doch von MyObjectList.free aufgerufen.. und die Schleife bei On-Close wird unnötig, bzw. sogar schädlich!

Hab vielen Dank und noch ein schönes Osterfest!

Wolfgang

Das verstehe ich nicht.. Wer wäre hier der Vorgänger? und wo muß das inherited hin?
meinst du so:



Welchen Unterschied macht das? Ich kann keinen erkennen beim Ablaufen lassen.

Das inherited (inherited; reicht hier, der Name der Funktion muss nicht explizit dahinter) muss beim Destroy natürlich ans Ende. Und der Vorfahr ist TObject sofern man nichts spezifisch angibt. Bei einem Destroy ohne override müsstest du eigentlich eine Compilermeldung bekommen dass die virtuelle Methode vom Basisobjekt verborgen wird.

Ich mache das übrigens teilweise auch mit einer TObjectList so dass ich alle Objekte sammle und sie damit automatisch freigeben lasse. Klappt hier seit Jahren wunderbar

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

gut, ich habs jetzt so:




Ja bei meinen bisherigen Klassen *hust* (die drei ohne die es einfach nicht ging) hab ich das auch so gemacht, aber ich habe auch nie gewagt in einer Klasse Objekte anderer Klassen zu erzeugen... Das war für mich bisher komplizierte Hexerei und böses Juju
Danke euch allen! Das Forum hier ist wirklich toll und hilfreich!

Eigentlich ist die Fehlermeldung "verbirgt Methode..." doch unsinnig, es müsste "wird verborgen von Methode..." heißen.

Schließlich würde der Aktiv bedeuten, dass die Destroy Methode von TObject vom eigenem Objekt verborgen wird, es müsste aber in Wahrheit passiv sein.

TObjects Methode verbirgt schließlich die Methode vom eigenem Objekt.

=> Entweder so oder:

Eigene Methode von Blabla wird von TObjects-Methode verborgen.

Die aktuelle Warnung ist irgendwie irre führend, oder nicht...?

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Nein, in diesem Fall ist es so richtig formuliert.
Es wird die Funktion von TObject überdeckt und nicht überschrieben.
Der Unterschied ist, dass TObject(Bla).destroy; die Funktion von TObject aufruft und erst Bla.destroy seinen eigenen Destruktor.
Der Grund weshalb das TMyMeasure.destroy nicht aufgerufen wird, ist das die Liste auf Basis von TObject arbeitet.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Hört sich zwar für mich immer noch zm. unlogisch an - aber was solls ^^

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)