Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Speicherleaks TMemoryStream in einem Objekt (https://www.delphipraxis.net/214313-speicherleaks-tmemorystream-einem-objekt.html)

QuickAndDirty 17. Jan 2024 09:02

AW: Speicherleaks TMemoryStream in einem Objekt
 
Zitat:

Zitat von himitsu (Beitrag 1532089)
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 17. Jan 2024 09:37

AW: Speicherleaks TMemoryStream in einem Objekt
 
Weil Pascal/Delphi "objektorientiert" ist :wink:

QuickAndDirty 17. Jan 2024 10:07

AW: Speicherleaks TMemoryStream in einem Objekt
 
Ich dachte interfaces/traits/behaviors gehören zum OO Baukasten dazu.

jaenicke 17. Jan 2024 12:08

AW: Speicherleaks TMemoryStream in einem Objekt
 
Zitat:

Zitat von himitsu (Beitrag 1532095)
Weil Pascal/Delphi "objektorientiert" ist :wink:

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz. 8-)

Zitat:

Zitat von QuickAndDirty (Beitrag 1532090)
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 17. Jan 2024 12:54

AW: Speicherleaks TMemoryStream in einem Objekt
 
Zitat:

Zitat von jaenicke (Beitrag 1532109)
Zitat:

Zitat von himitsu (Beitrag 1532095)
Weil Pascal/Delphi "objektorientiert" ist :wink:

Hinter einer Interfacereferenz steckt eine referenzgezählte Objektinstanz. 8-)

Zitat:

Zitat von QuickAndDirty (Beitrag 1532090)
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 17. Jan 2024 13:05

AW: Speicherleaks TMemoryStream in einem Objekt
 
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 18. Jan 2024 15:11

AW: Speicherleaks TMemoryStream in einem Objekt
 
Zitat:

Zitat von himitsu (Beitrag 1532112)
(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 26. Jan 2024 12:22

AW: Speicherleaks TMemoryStream in einem Objekt
 
Hallo Zusammen,

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

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

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

LG Patrick

stahli 31. Jan 2024 15:41

AW: Speicherleaks TMemoryStream in einem Objekt
 
Zu Interfaces habe ich mal ein paar Infos zusammengestellt: https://www.delphipraxis.net/183702-...-factorys.html


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:47 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz