Umgang mit Interfaces

**Patito**

Wer meint es besser zu wissen bzw. sein Anwendungsfall es unbedingt erfordert, muss ja nicht von TInterfacedObject ableiten,

Die RefCount Methoden kann man zwar überschreiben, aber die Grundproblematik von Delphi wird man dadurch nicht los.
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 von TiGü:

Die "automatische" Referenzverwaltung von Inferface-Objekten ist in meinen Augen sehr bequem und ermöglicht ein sehr komfortables modernes programmieren.

Ich denke, dass jemand, der "automatische" Referenzverwaltung für bequem hält, vom Thema insgesamt herzlich wenig verstanden hat.
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 von TiGü:

Hast du nur ein Objekt von Typ IInteger vorliegen, musst aber schauen ob ISomeThing unterstützt wird (oder umgekehrt) -> wie sollte man es sonst machen?

Ein Fehler (z.B. bei dem Problem mit der Liste) liegt schon an der Stelle, wo man so ein Objekt erzeugt und es dann in einen anonymen Container wirft. Eine bessere Lösung wäre die Objekte in typsicheren Listen zu speichern, und nicht erst zur Laufzeit die Objekte herauszufiltern. Wer Typsicherheit von der Compilezeit in die Laufzeit schiebt, darf sich nicht beschweren, dass es Probleme gibt.

**Daniel**

Zitat von Patito:

Ich denke, dass jemand, der "automatische" Referenzverwaltung für bequem hält, vom Thema insgesamt herzlich wenig verstanden hat.

Oder ist es anders herum der Fall? Warum sollte ich als ahnungslos gelten, wenn ich z.B. ARC verwende? Unter ObjectiveC habe ich z.B. gar keine andere Wahl. Du verteidigst hier flammend FreePascal - das ist fein für Dich, aber ein klein wenig solltest Du dennoch über den Tellerrand schauen.

**TiGü**

Zitat von Patito:

Zitat von TiGü:

Wer meint es besser zu wissen bzw. sein Anwendungsfall es unbedingt erfordert, muss ja nicht von TInterfacedObject ableiten,

Die RefCount Methoden kann man zwar überschreiben, aber die Grundproblematik von Delphi wird man dadurch nicht los.

Ehrlich gesagt kann ich dir jetzt nicht mehr so ganz folgen was denn die "Grundproblematik" sein soll.
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 von Patito:

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...

Dann lass es doch weiterhin lustig aufrufen.
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?

zusammenfalten · markieren

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 von Patito:

Zitat von TiGü:

Die "automatische" Referenzverwaltung von Inferface-Objekten ist in meinen Augen sehr bequem und ermöglicht ein sehr komfortables modernes programmieren.

Ich denke, dass jemand, der "automatische" Referenzverwaltung für bequem hält, vom Thema insgesamt herzlich wenig verstanden hat.
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.

Ja nun, ich denke mir mal meinen Teil dazu.
Es gab immer Leute die meinen es besser zu wissen.

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:

markieren

Delphi-Quellcode:

			 
var

  a, b, c : Integer;

begin

  a := 0;

  c := b div a;

end;

**JamesTKirk**

Zitat von TiGü:

Zitat von Patito:

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...

Dann lass es doch weiterhin lustig aufrufen.
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?

Mit COM Interfaces verhält sich FPC genauso wie Delphi, nur dass das Interface eventuell an anderen Orten als bei Delphi freigegeben wird. Auf was Patito anspielte sind CORBA bzw. Raw Interfaces, die wie COM Interfaces aussehen, aber nicht von IInterface erben und damit auch keine automatische Referenzzählung haben.

Gruß,
Sven

**himitsu**

Zitat von Patito:

Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde.

Dann liegt der Fehler aber auch bei dir.

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 von TiGü:

Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:

Der meckert doch?

B ist nicht initialisiert

Zitat von TiGü:

// folgendes funktioniert problemlos, obwohl das Objekt freigeben wurde!

Die Speicherverwaltung ht den speicher aber "oftmals" noch nicht sofort freigegeben.

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.

**TiGü**

Zitat von himitsu:

Zitat von TiGü:

Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:

Der meckert doch?

B ist nicht initialisiert

Zitat von himitsu:

PS: Zugrif auf "ungültige" Zeiger .... wie oben erwähnt.
Das Objekt ist weg, aber DU hast den Instanzzeiger in MySomeThingObject nicht bereinigt.

Eben das wollte ich zeigen!
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:

zusammenfalten · markieren

Delphi-Quellcode:

			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;

Von daher soll der Compiler doch ruhig in die eigenen _AddRef- und _Release-Methoden springen, wenn man meint sowas brauchen zu müssen!

**Whookie**

Ich seh schon ... heißes Thema

...

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

!

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)...

**TiGü**

Zitat von Whookie:

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)...

Mir ist nicht ganz klar, worauf das Testprogramm abzielt, aber im Anhang findest du eine Version ohne Speicherleck.
Man kann sich die TObjectList<T> und die Item-Klasse komplett sparen, aber ich merke du hast mein Beispiel mit dem Dictionary weiter oben auch nicht wirklich näher ausprobiert und/oder verstanden.

Ansonsten merkt man am Quelltext, dass du häufig viel zu kompliziert denkst und durch die Brust-ins-Auge-Lösungen bevorzugst.

Zitat von OlafSt:

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi

Interfaces werden seit Delphi 4 unterstützt, das sind auch schon ein paar Tage länger.
Hätte man sich auch mal zwischenzeitlich mit beschäftigen können...

**OlafSt**

Zitat von TiGü:

Zitat von Whookie:

Das ist mir klar, ich programmier schon ein paar Tage länger mit Delphi

Interfaces werden seit Delphi 4 unterstützt, das sind auch schon ein paar Tage länger.
Hätte man sich auch mal zwischenzeitlich mit beschäftigen können...

Wie man an meinem Vorposter sieht, war es doch nicht so verkehrt, sich lieber mit Generics oder anderen wichtigen Neuerungen zu befassen als mit dieser halblebendigen Implementation seine Zeit zu vergeuden

In C# oder gar C++ wird mir das hier gelernte aber deutlich weiterhelfen.

**Der schöne Günther**

Weak References gibt es ja schon länger auf dem "Nextgen"-Compiler. Da mich der nicht interessiert, hoffe ich seit langem darauf, dass das endlich mal für den Desktop kommt (

http://www.delphipraxis.net/176352-w...-compiler.html)

Gerade auf dem Desktop versucht ja auch Emba immer bis zu Julius Caesar rückwärtskompatibel zu sein. Aber was ist mit neuen Projekten die keine Altlasten mehr unterstützen müssen?