Speicherleaks TMemoryStream in einem Objekt

[QuickAndDirty]

Zitat von himitsu:

Leider ist von Microsoft das IStream nicht kompatibel mit Delphis TStream (von den Methoden her)
und für die Verwendung braucht man ja immernoch das Delphi-Objekt.

Warum wurde TStream nicht gleich als Interface umgesetzt?

[himitsu]

Weil Pascal/Delphi "objektorientiert" ist

[QuickAndDirty]

Ich dachte interfaces/traits/behaviors gehören zum OO Baukasten dazu.

[jaenicke]

Zitat von himitsu:

Weil Pascal/Delphi "objektorientiert" ist

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz.

Zitat von QuickAndDirty:

Warum wurde TStream nicht gleich als Interface umgesetzt?

Das wäre sicherlich an einigen Stellen wünschenswert (TList, TDictionary, TStream, TDataset, ...), aber wenn dann jemand diese Klassen als Objektreferenzen einsetzt und irgendwo aus Versehen als Interface übergibt, wäre das doof. Insofern ist es schon auch schwierig, wenn solche Klassen auch als Interface angeboten würden. Und nur als Interface wäre wieder u.a. ein Performancethema und nachträglich kaum machbar.

[QuickAndDirty]

Zitat von jaenicke:

Zitat von himitsu:

Weil Pascal/Delphi "objektorientiert" ist

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz.

Zitat von QuickAndDirty:

Warum wurde TStream nicht gleich als Interface umgesetzt?

Das wäre sicherlich an einigen Stellen wünschenswert (TList, TDictionary, TStream, TDataset, ...), aber wenn dann jemand diese Klassen als Objektreferenzen einsetzt und irgendwo aus Versehen als Interface übergibt, wäre das doof. Insofern ist es schon auch schwierig, wenn solche Klassen auch als Interface angeboten würden. Und nur als Interface wäre wieder u.a. ein Performancethema und nachträglich kaum machbar.

Es hat trotzdem einen Vorteil wenn man "Just-In-Case" für all diese basic-klassen ein Interface hätte welches sie auch implementieren...
Im Falle von tDatabase wäre es eine NICHT Arc implementierung, aber so hätte man trotzdem noch Möglichkeiten was Auslagerung in DLLs und Reduzierung von Abhängigkeiten betrifft.

[himitsu]

Das Problem ist halt, dass man nicht-referenzgezählte Objekt-Instanzen und Interfaces niemals gleichzeitig auf das "selbe" Objekt haben darf/sollte.

Bzw. bei TComponent ist es "standardmäßig" so, dass optional anhängbare Interfaces nicht referenzgezählt sind.
Jene sollte/darf man somit auch immer nur kurz benutzen und die Interface-Instanz sofort wieder freigeben.
Da hier ausschließich das Objekt die Speicherverwaltung übernimmt, also Free, der Owner, sowie auch der Parent (hat sich Delphi leider von der GDI abgeguckt).

Die Interface-Refrenz wird bei TComponent-Nachfahren also "ungültig", wenn das Objekt freigegeben wird.
Ein NIL zuweisen geht danach dann auch nicht mehr, sowie wenn die Variable aus dem Scope rausläuft, da es versuchen würde IInterface._Release auszuführen, was aber nicht mehr ginge.
Hier sollte man dann am Besten mit [Weak]-Referenzen arbeiten (was aber fast niemand tut).

Hätte man dagegen ein referenzgezähltes Interface, dann würden Jene das Objekt freigeben und die Objekt-Referenzen wären plötzlich alle ungültig.

Zusammen mit ARC wäre so ein Mischbetrieb aber möglich. (wobei ich dennoch froh bin, dass ARC wieder gestorben ist, weil es andere konzeptionelle Nachteile hatte)

[QuickAndDirty]

Zitat von himitsu:

(wobei ich dennoch froh bin, dass ARC wieder gestorben ist, weil es andere konzeptionelle Nachteile hatte)

Ja, ARC bedeutet alle Nachteile einer GC aber ohne die schwerer wiegenden Vorteile einer GC .

[Ykcim]

Hallo Zusammen,

ich nutze Delphi seit ca. 15 Jahren hobbymäßig... Aber ab #Post19 brauche ich ein Wörterbuch

Ich werde in den nächsten Wochen Zuhause die Programmgruppe neu aufbauen und mir das Wörterbuch deneben legen.

Vielen Dank für die vielen Anregungen, ich werde berichten!

LG Patrick

[stahli]

Zu Interfaces habe ich mal ein paar Infos zusammengestellt: https://www.delphipraxis.net/183702-...-factorys.html