MemoryLeak bei TList<IMyInterface>

[stahli]

@himi

Einen IchVerneigeMichVorDir-Smily hat die DP ja nicht - hilfsweise dann so:

Das klingt einleuchtend und plausibel. Aber wie bekommt man das raus?


@Stevie

Das MemoryLeak ist woanders verursacht. Mein 1:2-Problem ergab sich als Fragestellung zwischendurch bei der Fehlersuche, ist aber nicht Fehlerverursachend.

[himitsu]

Jupp, kein Speicherleck ... zwei Variablen = zwei Referenzen

Zitat von stahli:

Aber wie bekommt man das raus?

Das weiß man.

Oder man versucht rauszubekommen was man im Assembler sieht.
Aber so ist es die einzige sichere Möglichkeit, den Speicher/Referenzen auch bei Exceptions konsistent zu halten, also indem man den Speicher außenrum absichert.
Die Result-Variable wird ja bei Exceptions einfach "ignoriert" und nicht weiter behandelt.

[stahli]

Jetzt wieder zum eigentlichen Thema: gegenseitige Referenzierung IListe <-> IEintrag ...

Ein klassischer Lösungsansatz geht offenbar über TAggregatedObject.
Das Pointergeschiebe ist mir aber irgendwie suspekt (genauer gesagt verstehe ich das nicht ausreichend und erscheint mir das recht unsicher).

Mir erscheint es für meinen Anwendungsfall sinnvoller, auf die automatische Referenzzählung zu verzichten.
Diese finde ich (wenn es um Datenklassen geht) auch etwas fragwürdig.

Ein abstraktes Beispiel: Ich habe ein Spiel mit einer Straße und einem Gullydeckel. Der Gullydeckel wird gesprengt (FreeAndNil bzw. :=nil).
Wenn jetzt irgendeine Variable noch eine Instanz darauf hält, existiert der Deckel noch und die Figur kann weiter darüber laufen - tatsächlich müsste sie aber in das Loch fallen oder ein Fehler auftreten.

Da ich meine Objekte ohnehin alle selbst verwalte und dies innerhalb meines geschlossenen Projektes, kann ich mir auch die Kontrolle über meine Objekte vorbehalten. Implementation von klassenübergreifenden Funktionalitäten (als eigentlichen großen Vorteil von Interfaces) kann ich ja weiter über Interfaces realisieren.

So sollten auch gegenseitigen Referenzierungen kein Problem mehr darstellen (wenn ich das intern ordentlich verwalte - dafür gibt es ja wieder verschiedene Ansätze).

Will da jemand Veto einlegen?


Falls jemand zu dem Thema nachlesen will, hier mal meine gefundenen Links:
http://www.delphipraxis.net/331268-post6.html
http://www.delphipraxis.net/812576-post5.html
http://www.delphipraxis.net/176352-w...-compiler.html
http://www.delphipraxis.net/178822-d...verhalten.html
http://www.delphipraxis.net/177999-w...tedobject.html
http://www.delphipraxis.net/919620-post5.html <-- so sehe ich das jetzt auch
http://www.delphipraxis.net/155315-i...zzaehlung.html
http://forum.delphi-treff.de/index.p...-deaktivieren/

[Stevie]

Wie immer heißt es hier: kommt drauf an

Ich unterscheide schon seit einiger Zeit Klassen in Daten- und Serviceklassen.

Siehe dazu diesen interessanten Artikel.
Das ist, wie er dort erläutert, auch bei DI wichtig.

Und aus diesem Grunde vermeide ich es auch, in den Datenobjekten zu viel Logik unterzubringen, die möglicherweise Abhängigkeiten auf Services nach sich ziehen.

[himitsu]

Wenn ich mir die fremden Umbauten an meinem Beispielcode anseh, dann macht dort jemand scheinbar Unittests.
Kann also nicht mehr lange dauern, bis zur Problemlösung.

https://quality.embarcadero.com/browse/RSP-10100