AW: Umgang mit Interfaces
Ich habe in meinem Leben bislang nie den Mut gehabt, mir den Assemblercode anzuschauen, der für die Referenzzählung oder das Werfen einer Exception entsteht.
Dann würde ich jedes mal wenn ich in einer Methode mittels Interface-Variable über irgendetwas iterieren,ein schlechtes Gewissen bekommen und würde meines Lebens nicht mehr froh. Ja, mir ging es jetzt nur um meinen persönlichen Komfort im Quelltext. Wie sehr der PC dann später zusätzlich schuften muss habe ich jetzt nicht bedacht... |
AW: Umgang mit Interfaces
Zitat:
Mit einem normalen Objekt hättest du ein Speicherleck! |
AW: Umgang mit Interfaces
Zitat:
|
AW: Umgang mit Interfaces
Zitat:
Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde. Die zur Zeit einzig sinnvolle Lösung für das Problem nennt sich Free-Pascal... Zitat:
Das ist fast genauso beknackt wie die Forderung der ActiveX Retro-Gurus, dass man Objekte und Interfaces nicht mischen sollte. Leute. Nehmt einfach einen vernünftigen Compiler und reitet nicht für immer rum auf diesen Lehrsätzen für COM-Interfaces, die Microsoft mal in der Antike verkündet hat. Zitat:
|
AW: Umgang mit Interfaces
Zitat:
|
AW: Umgang mit Interfaces
Zitat:
Kannst du hierauf nochmal eingehen? Das es COM-Interfaces sind - also einen gewissen sprachübergreifenden Standard folgen - ist jetzt aber nicht das "Problem", oder? Zitat:
Solange du in den selbstimplementierten _AddRef und _Release Methoden kein Schindluder betreibst geht das doch?!? Wo ist das Problem? Oder verhält sich das in Free-Pascal anderes?
Delphi-Quellcode:
ISomeThing = Interface(IInterface)
['{16CCA417-F4C4-4B4A-88CE-FDD79B875876}'] function DoSomeThing : Integer; End; TMyInterfacedObject = class(TObject, IInterface) protected function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; end; TMyDoSomething = Class(TMyInterfacedObject, ISomeThing) protected function DoSomeThing : Integer; end; ... function TMyInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult; begin if GetInterface(IID, Obj) then Result := 0 else Result := E_NOINTERFACE; end; function TMyInterfacedObject._AddRef: Integer; begin Result := -1; end; function TMyInterfacedObject._Release: Integer; begin Result := -1; end; ... var MySomeThingObject : ISomeThing; begin MySomeThingObject := TMyDoSomething.Create; MySomeThingObject.DoSomeThing; (MySomeThingObject as TMyDoSomething).Free; // folgendes funktioniert problemlos, obwohl das Objekt freigeben wurde! MySomeThingObject._AddRef; MySomeThingObject._AddRef; MySomeThingObject._AddRef; MySomeThingObject._Release; end; Zitat:
Es gab immer Leute die meinen es besser zu wissen. :stupid: COM ist aktueller denn je, weiß nicht was das mit Antike zu tun haben sollte. Mein Rechner läuft auf Windows 8.1 und da ist das "Kachelstartmenü" durchgehend mit dieser Technologie umgesetzt. Zeige uns doch bitte mal einen typischen Anwendungsfall in deiner Applikation, wo der Einsatz von COM-Interfaces zu Fehlern führt und stattdessen das von dir gewünschte Verhalten besser wäre. In meiner Applikation sind ein Großteil der Klassen über Interfaces ansprechbar und das nicht mischen von Objekt- und Interfacereferenzen gewöhnt man sich auch schnell an. Weiß nicht worin da die Schwierigkeit besteht das konsequent durchzuziehen. Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:
Delphi-Quellcode:
var a, b, c : Integer; begin a := 0; c := b div a; end; |
AW: Umgang mit Interfaces
Zitat:
Wenn du "referenzählende" Variablen hast, und du denen unterm Arsch weg die Objekte klaust, wovon die natürlich nichts mitbekommen, dann können die nur davon ausgehen, daß die darin verlinkte Instanz gültig ist und es werden die Referenzen gezählt (bzw. es wird versucht). - Entweder es wird über die Referenzzählung der Speicher freigegeben - und wenn nicht, dann darf die Variable nicht referenzzählend sein - oder du mußt die referenzzählende Variable auf nil setzen (unter böswilliger Umgehung der Referenzzählung), sobald du das Objekt freigibst, oder bevor die Variable freigegeben wird, bzw. bevor sie einen neuen Wert bekommt - und es darf auch keiner mehr die "ungültige" Referenz daraus verwenden Zitat:
B ist nicht initialisiert :stupid: Zitat:
Das kann man aber zum Debuggen beheben. - FastMM entsprechend einstellen - oder einen Debug-Speichermanager verwenden welche die Objektinstanzen zerstören/überschreiben, womit des beim nächsten Zugriff knallt PS: Zugrif auf "ungültige" Zeiger .... wie oben erwähnt. Das Objekt ist weg, aber DU hast den Instanzzeiger in MySomeThingObject nicht bereinigt. |
AW: Umgang mit Interfaces
Zitat:
Zitat:
Solange der Pointer nicht ungültig wird, wird ja auch beliebig in die Methoden gesprungen. Wenn hier fröhlich Interface- und Objektreferenzen gemischt werden (sollt ihr dafür alle in der Hölle schmoren) dann geht auch folgends:
Delphi-Quellcode:
Von daher soll der Compiler doch ruhig in die eigenen _AddRef- und _Release-Methoden springen, wenn man meint sowas brauchen zu müssen!
function TMyDoSomething.DoSomeThing : Integer;
begin Result := 123; end; procedure TForm1.Button2Click(Sender: TObject); var MySomeThingObject : TMyDoSomething; MagicNumber : Integer; begin // MySomeThingObject := TMyDoSomething.Create; MagicNumber := MySomeThingObject.DoSomeThing; // MagicNumber hat jetzt den Wert 123, obwohl kein Objekt erzeugt wurde! Schwarze Magie? ;-) end; |
AW: Umgang mit Interfaces
Liste der Anhänge anzeigen (Anzahl: 1)
Ich seh schon ... heißes Thema :twisted: ...
Da es mir aber um die Implementierung mit Interfaces geht habe ich das ganze nochmals vereinfacht und komplett auf Interfaces umgestellt. Dazu gibts ein eigenes IAdmin-Interface in dem die Sachen definiert sind die vorher eben nur in der Objektinstanz zur Verfügung standen. Die Implementierung habe ich hier angehängt weil es noch ein Problem bei der Verwaltung der Interfaces gibt und ja, ohne FastMM gibts keine vernünftige Delphi-Entwicklung :stupid:! Nochmals zur Erklärung: Die "Hauptliste" (fIntfLst) wird aus einer Textdatei erstellt, es gibt um die 20 verschiedenen Klassen die aus der Kombination von ca. 10 Interfaces bestehen. Diese "Knoten" stehen noch untereinander in Beziehung und daher speichern die Knoten diese Beziehungen in privaten Listen (wie z.B.: TTest.fMyNodes)... Eigentlich dachte ich ja, das bei reiner Interface-Verwendung keine Probleme mehr auftreten, aber irgendwie schaffe ich es durch meine Querverlinkung die Referenzzählung durcheinander zu bringen (siehe uImpl.pas Zeile 170)... |
AW: Umgang mit Interfaces
Wenn der Speichermanager aufräumt, dann wird es auch knallen. Oder wenn inzwischen etwas Anderes an der Stelle steht, dann produziert man damit einen Buffer-Overrun,
wenn man auf ungültige Variablen zugreift. Und das ist nicht erst seit Interfaces so.
Delphi-Quellcode:
var
o: TMyIrgendwas; o := TMyIrgendwas.Create; o.Free; o.DoWas; // Fehler o := TMyIrgendwas.Create; FreeAndNil(o); o.DoWas; // Zugriffsverletzung bei Addresse 0 Man kann gern die Speicherverwaltung komplett der Referenzzählung des Interfaces überlassen. Und wenn es unbedingt sein muß, dann holt man sich "kurzzeitig" nochmal eine Objekt-Referenz aus dem Interface raus (an dieser Stelle muß parallel eine Interface-Referenz vorhanden sein), denn Delphi bietet seit einer Weile ein Pseudo-Interface an, welches die Objektreferenz zurückgibt. (wenn im Interface ein Delphi-Objekt steckt) Und an diese Objektreferenz kommt man z.B. via
Delphi-Quellcode:
ran.
intf AS TObject
Man kann natürlich auch eigene Getter in seinem Interface verbauen, welches Objekt-Instanzen zurückgibt. Sobald dann die "paralelle" Interface-Referenz freigegeben wird, ist die Objektreferenz als "ungültig" anzusehen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:43 Uhr. |
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