Interface referenzen auf gleichheit prüfen?

[choose]

Es bleibt maximovs Einwand, dass diese Information eigentlich schon implizit vorhanden und gegeben ist durch die Identät des Objekts. Darüber hinaus sehe ich keine triviale Lösung, beschriebenes Konzept zu generalisieren, also auch auf solche Objekte anzuwenden, deren Klassen man nicht selbst implementiert hat.
Außerdem erwarte ich, wie maximov, dass eine Spache selbst in der Lage ist, auf Identität gemäß der Referenzsemantik prüfen zu lassen. Der von mir beschriebene Ansatz, zwei Referenzen auf das identische Objekte "noch gleicher" zu machen, ist kein Trick, funktioniert auf der Grundlage der wohldokumentierten und (für uns Delphianer) unveränderlichen COM-Interface-Implementierung unter Win32, und ist genauso gültig nach dem allgemeinen Konzept von Schnittstellen in der OOP.

[negaH]

Nein, dein Weg funktioniert eben nicht. Der AS Operator ist ein verkapselter Aufruf von A.QueryInterface(var B, GUID: TGUID). D.h. der Code

Delphi-Quellcode:

  A := B as IInterfaceType

ist identisch mit

  if B.QueryInterface(A, IInterfaceType) <> S_OK then raise Exception.Create(...);

So erstmal der erste Schritt, nun der zweite:

Eine Impelentierende Klasse kann nun .QueryInterface() überschreiben und dynamisch auf Anforderung ein neues Implemntierendes Object erzeugen das die geforderte Schnittstelle implementiert, also in etwa so:

Delphi-Quellcode:

function TClassA.QueryInterface(var Unk; const GUID: TGUID): HResult; stdcall;
begin
  Result := S_OK;
  if GUID = IInterfaceType then IInterface(Unk) := TImplementorClass.Create 
    else Result := inherited QueryInterface(Unk, GUID);
end;

In diesem Moment erzeugt also die Klasse TClassA ein ganz neues Object das die geforderte Schnittstelle IInterfaceType tatsächlich implementiert. Bei solch einer Implementierung, die sehr oft verwendet wird, kann dein einfacher Vergleich der Variablenpointer nicht mehr funktionieren, denn nun würde ja alles, selbst die Impelemntierende Klasse vollständig von der eigentlichen Klasse gekapselt sein.

Also sowas wie:

Delphi-Quellcode:

var
  A,B,C: IInterface;
begin
  A := TClassA.Create;
  
  B := A as IInterfaceType;
  C := A as IInterfaceType;

  Assert( B <> C );
end;

B ist immer ungleich C da der cast (A as IInterfaceType) -> A.QueryInterface() eben intern bei jeder Abfrage ein eigenes neues Interface erzeugt.

Zitat:

Es bleibt maximovs Einwand, dass diese Information eigentlich schon implizit vorhanden und gegeben ist durch die Identät des Objekts.

Und das stimmt eben nicht. Interfaces besitzen per Konzept keine Identität auf deren Implementierung und somit kann auch eine Delphi VCL Klasse nicht ihre implementierende und eindeutige Klassen-Identität auf deren implementierte Interfaces übertragen. Der Weg den die RT /bzw. der Delphi Compiler die Interfaces im Klassendesign über die RTTI umsetzt ist absolut Delphi typisch und nicht dokumentiert. Andere Compiler können das komplett anders handhaben.

Der Delphi Compiler legt im Codesegement die VMT des Interfaces als Konstante an. Die einzelnen Methoden dieses Interfaces zeigen eber nicht direkt auf die Methoden der implementierenden Klasse sondern auf Dispatcher Methoden die durch den Compiler erzeugt wurden. Für jede Methode im Interface gibt es eine eigene Dispatcher Funktion. Diese Dispatcherfunktion berechnet nun aus dem übergebenen Interface Zeiger per Offset den Self Zeiger des Objectes. Dieser Offset ist für jede Interface implementierende Klasse und für jedes einzelene Interface dieser Klasse selber unterschiedlich.

Nun, auch wenn man dies weis und als Ausgangsbasis für eine Identität zum direkten Vergleich von Interfacezegern heranziehen könnte, so ist diese Art und Weise der Impelemntierung von Interfaces eben Delphi typisch und zudem auch undokumentiert.

Nein, das was ich oben sagte stimmt auch weiterhin. Maximov sollte überlegen ob sein Konzept richtig ist, und ob er nicht zuviel von den Interfaces abverlangt. Mein oben vorgeschlagener Weg ist eine saubere Lösung, und für meine Begriffe die einzigst saubere überhaupt. Denn selbst wenn Delphi die Art und Weise wie es Interfaces mit Klassen/Objecten verbindet ändert, oder sogar wenn man auf diese Weise Interfaces die durch verschiedene Compiler erzeugt wurden, vergleicht, so funktioniert das immer sauber.

Gruß Hagen

[choose]

Hallo Hagen,

Zitat von Hagen:

Mein oben vorgeschlagener Weg ist eine saubere Lösung, und für meine Begriffe die einzigst saubere überhaupt. Denn selbst wenn Delphi die Art und Weise wie es Interfaces mit Klassen/Objecten verbindet ändert, oder sogar wenn man auf diese Weise Interfaces die durch verschiedene Compiler erzeugt wurden, vergleicht, so funktioniert das immer sauber.

ich stimme Dir in diesem Punkt absolut zu! Allerdings bietet Sie nach wie vor keine Lösung für eine Situation, bei der die Implementierung der Basisklasse unveränderlich ist. Außerdem möchte ich auf einige Punkte Deiner Darstellung erneut eingehen, weil ich sie nicht nachvollziehen kann.

Der von Dir dargestellte Code

Delphi-Quellcode:

var
  A,B,C: IInterface;
begin
  A := TClassA.Create;
  
  B := A as IInterfaceType;
  C := A as IInterfaceType;

  Assert( B <> C );
end;

funktioniert bei mir mir in den Delphi Versionen 5, 6 und 7 so, wie von mir beschrieben: Die Zusicherung schlägt fehl, oder mit anderen Worten: Es gilt
B = C; Und das "Konzept" der Interfaces entspricht im Gedanken denen des "Typen" (vgl Booch), also "Sichten" auf Objekte. Sie abstrahieren vom Verhalten einer Klasse und führen lediglich das Protokoll (in Form der Signaturen der Nachrichten), mit dessen Hilfe der Klient mit Ihnen interagieren kann, ein. Trotz dieser Sicht verbirgt sich hinter einer solchen Interfacereferenz also ein (Proxy-)Objekt und hat somit eine Identität inne.
Objekte könnten also durch Stellvetreter (Proxies) dynamisch bei jeder Zuweisung generiert werden und ganze Programmkonzepte (zB dynamische Proxies unter Java oder div Persistenz-Frameworks unter Smalltalk arbeiten nach diesem Prinzip) beruhen auf diesem Ansatz. Der Delphi-Compiler allerdings bedient sich jedoch eines anderen Ansatzes, der einen Mittelweg zwischen Performance und Speicherbedarf beschreibt.



Im Folgenden möchte ich Zeigen, dass die Interfacereferenz nicht nur im allgemeinenen sondern auch bei der Delphi-Implementierung nach dm COM-Interface-Paradigma ein direkter Zusammenhang zur Objektidentität existiert.

Während bei einem virtuellen Aufruf eines Objekts einer Klasse der Compiler die Basisklasse eines Objekts bereits zur Übersetzungszeit kennt und er die Klasse eines Objekts zur Laufzeit ermitteln kann, hat er die Möglichkeit, in der VMT der Klasse nach der durch die Basisklasse angeführten Stelle die Referenz auf die Methode allein durch die indirekte Kenntnis der Objektklasse durch die Referenz auf das Objekt zu erlangen.
Bei einer Referenz auf ein Interface wurde wieder dieser weg Beschritten, weil es hier keine Basisklasse gibt, auch wurde kein Slot-Mechnismus wie bei dynamischen Methoden oder Message Methoden verwendet:

Code:

Jede Klasse besitzt eine "Methodentabelle" pro Interface, dass sie implementiert.

Weil zwei Interfaces voneinander erben können, die Implementierung einer Methode, die durch das "Oberinterface" jedoch gänzlich von der Implementierung des "Unterinterface" verschieden sein kann, ist der direkte Abgriff an der Stelle, die durch diesen "Vorfahren" eingeführt wurde, nicht möglich, so dass der Ansatz von Delphi etwas anders aussieht (ich beschreibe den letzten Teil des Castes, der, wie bereits von Dir beschrieben auf der Methode QueryInterface beruht, die ihrerseits GetInterface verwendet):

Delphi-Quellcode:

function TObject.GetInterface(const IID: TGUID; out Obj): Boolean;
var
  InterfaceEntry: PInterfaceEntry;
begin
  Pointer(Obj) := nil;
  InterfaceEntry := GetInterfaceEntry(IID);
  if InterfaceEntry <> nil then
  begin
    if InterfaceEntry^.IOffset <> 0 then
    begin
      Pointer(Obj) := Pointer(Integer(Self) + InterfaceEntry^.IOffset);
      if Pointer(Obj) <> nil then IInterface(Obj)._AddRef;
    end
    else
      IInterface(Obj) := InvokeImplGetter(Self, InterfaceEntry^.ImplGetter);
  end;
  Result := Pointer(Obj) <> nil;
end;

Die Methode GetInterface hat die Aufgabe, in den Parameter Out eine Interfacereferenz auf die durch IID beschriebene Schnittstelle zum betrachteten Objekt zurückzugeben, sofern vorhanden. Der Bool'sche Rückgabewert signalisiert den Erfolg der Operation.

InterfaceEntry := GetInterfaceEntry(IID); Dieser Aufruf der Klassenmethode GetInterfaceEntry ermittelt (indirekt) die bereits zuvor beschriebene VMT der Klasse zum Interface. Der Rückgabewert des Aufrufs ist für alle Exemplare der Klasse identisch und nil, falls die Klasse das Interface nicht implementiert. Betrachtet man den Aufbau der Struktur, auf die eine Referenz zurückgegeben wird, etwas genauer

Delphi-Quellcode:

type
  TInterfaceEntry = packed record
    IID: TGUID;
    VTable: Pointer;
    IOffset: Integer;
    ImplGetter: Integer;
  end;

fällt auf, dass sie eine Referenz auf die tatsächliche VMT enthält (VTable) und die GUID des Interface enthält, letztere ist für die Methoden GetInterfaceEntry erforderlich.
Interessant für die weitere Betrachtung ist das Feld IOffset. Betrachtet man die Implementierung von GetInterface weiter

Delphi-Quellcode:

if InterfaceEntry^.IOffset <> 0 then
begin
  Pointer(Obj) := Pointer(Integer(Self) + InterfaceEntry^.IOffset);
  if Pointer(Obj) <> nil then IInterface(Obj)._AddRef;
end

so erkennt man, dass dieser Offset einfach zu dem Speicherbereichsbeginn des Objekts selbst addiert wird. Der so ermittelte Wert ist (im Regelfall) dann die Interfacereferenz.

Wie also zu erkennen ist, muss der Wert von GetInterface bei jedem Aufruf an dasselbe Objekt den identischen Rückgabewert haben, weil IOffset von der zu einem (Delphi-)Objekt unveränderlichen Klasse und der andere Summand von dem (für Delphiobjekte unveränderlichen) Speicherort abhängt (der bei Delphiobjekte der Identität entspricht).


Um zu klären, wie der Compiler Code zum Aufruf einer Methode erzeugen kann, ohne Kenntnis über die Klasse eines Objekts, zu dem eine Interfacereferenz bekannt ist, zu haben, verfolgt man im Debugger, was an der Stelle
Verfolgt man im Debugger, was an der Stelle
Pointer(Integer(Self) + InterfaceEntry^.IOffset) zu finden ist.
Entdecken kann man bei einem Aufruf der Art
MyInterfaceRef.AnOperationIntrocuedByMyInterface; eine Technik, die auch bei diversen anderen Stellen durch den Delphi-Compiler erzeugt wird:

Code:

  ; MyInterfaceRef = InterfaceReferenz = Objektrefernz+IOffset
  ;  Hier: IOffset = 16d = $10
  mov   eax, [MyInterfaceRef]  ; eax => "magischer Zeiger" mit Objektreferenz+IOffset (s.o.)
  mov   edx, [eax]             ; edx => "magischer Bereich"
  call  edx, [edx+$0c]         ; Sprung nach [edx+Methodenselektor]

Code:

  ; "magische Tabelle" hinter der Klasse
  ;   mit IOffset = 16d = $10
  add   eax, -$10              ; eax = "magischer Zeiger"-IOffset = Objektreferenz
  jmp   TMyClass.AnOperationIntroducedByMyInterface

Nach diesen Zeilen also wird die Methode AnOperationIntroducedByMyInterface aufgerufen und in eax befindet sich, gemäß der Delphi-Aufruf-Konvention nach Registern, die Referenz auf das Objekt, um Zugriffe auf die Pseudovariable Self zu ermöglichen.

Verfolgen wir den Verlauf von eax fällt auf, dass es zunächst mit der Interfacereferenz (=Objektreferenz+IOffset, siehe oben) beladen wurde und anschließend, in einer "magischen Sprungtabelle" durch harten Quelltext um den für die Klasse konstanten Wert von IOffset dekrementiert wird, um -wieder hart im Code pro Klasse- zur entsprechenden Methode zu springen.
Die tatsächliche Unterscheidung, welche Implementierung verwendet werden soll, wird also innerhalb des "magischen Bereichs" innerhalb des Speicherbereichs des Objekts getroffen: Hier wird pro Objekt eine Referenz auf den "Beginn" der "magischen Sprungtabelle", deren Struktur für alle Klassen identisch ist, abgelegt; Ein Zeiger pro Objekt.

Wir haben es also mit einer doppelten Indirektion zu tun, die dynamisch aufgelöst werden kann und deren veriablen Anteile die InterfaceReferenz, einem Zeiger auf die Objektreferenz plus einem für die Klasse-Interface-Kombination konstanten Offset IOffset sowie einem bei der Anlage eines Objekts erzeugten Verweis an dieser Stelle auf die "Methodentabelle" der Klasse für ein konkretes Interface, die, im Wissen um IOffset (weil konstant und zur Übersetzungszeit bekannt), die Objektreferenz rekonstruieren kann.


Ich hoffe, ich konnte zeigen, dass es keinen Grund für die Trennung zwischen der Identität eines Objekts und der eines Interface gibt und dass bei Delphi 5, 6 und 7 (ich habe die früheren Compiler leider nicht zur Hand) zumindest eine direkte Abhängigkeit zwischen den Objekt- und Interfacereferenzen bestehen, die unter Delphi der Identität entspricht.

Diese Erkenntnis:

Code:

In Delphi 5, 6 und 7 entspricht die Interfacereferenz [i]IRef[/i] des Interfacetyps [i]ITyp[/i] immer der Objektreferenz [i]ORef[/i] plus einem konstanten Wert [i]ClassTyp.IOffset(ITyp)[/i] seiner Klasse [i]ClassTyp[/i] in Abhängigkeit des betrachteten Interfacetyps.
Es gilt für beliebige aber feste [i]ORef[/i], [i]ITyp[/i] mit [i]ClassTyp = ORef.ClassTyp[/i] daher
  ORef.ClassTyp.IOffset(ITyp) = const
und somit
  IRef = ORef + ORef.ClassTyp.IOffset(ITyp) = const

kann nun mit dem Wissen, dass TInterfacedObject das Interface IInterface implementiert, verwendet werden, um von der Identität der Interfacereferenzen IRef1 und IRef2 eben dieses Typs auf die Objektidentität zu schließen, gemäß der Folgerung

Code:

 ORef1 = ORef2    =>    IRef1 = IRef2

und der aus Zeitgründen nicht hinreichend gezeigten Beschaffenheit von IOffset (es gilt: Für alle gültigen IOffset, ORef : IOffset<=ORef.InstanceSizePlusMagic, so dass insbesondere die Kombination niemals "in" den Speicherbereich eines von ORef verschiedenen Objekts zeigt) folglich gilt:

Code:

 ORef1 = ORef2    <=    IRef1 = IRef2

(man verzeihe mir bitte, diese etwas "pragmatische Darstellung").


Der Test nach

Delphi-Quellcode:

Result := (AnInterfaceRefOfAnObjectThatImplementsIInterface as IInterface)
  = (AnotherInterfaceRefOfAnObjectThatAlsoImplementsIInterface as IInterface);

ist somit auch unter Delphi möglich.


Interessant ist nun noch die Betrachtung von TInterfaceEntry.ImplGetter aber ich glaube, dass dies nach diesem trockenen Stoff niemanden mehr interessiert

[negaH]

Hi Choose,

so langsam nähern wir uns dem Punkt:

Delphi-Quellcode:

  mov   eax, [MyInterfaceRef]  ; eax => "magischer Zeiger" mit Objektreferenz+IOffset (s.o.) 
  mov   edx, [eax]             ; edx => "magischer Bereich" 
  call  edx, [edx+$0c]         ; Sprung nach [edx+Methodenselektor]

ist natürlich nicht ganz richtig erklärt

Delphi-Quellcode:

  mov   eax, [MyInterfaceRef]  ; lade eax mit Interface aus Variable MyInterfaceRef
  mov   edx, [eax]             ; lade edx mit VMT des Interfaces
  call  edx, [edx+$0c]         ; spinge indirect an die Addresse die in der Interface VMT an Index 3 steht, eg. rufe .AnOperationIntrocuedByMyInterface Dispatcher auf

Allerdings stehtin der VMT eben NICHT der direkte Aufruf von .AnOperationIntrocuedByMyInterface drinnen sondern eine Addresse zu einem durch den Compiler erzeugten Disptacher. Dieser Dispatcher "subtrahiert" von der aktuelle Intrface Referenez in EAX = Self.Interface den IOffset und springt danach zu .AnOperationIntrocuedByMyInterface.

Nun dieser Mechanismus ist natürlich in Delphi 5,5,7 gleich geblieben, und stellt auch tatsächlich einen direkten Zusammenhang zu den implementirenden Klassen dar. Das ist alles richtig. ABER, diese Funktionalität ist eben undokumentiert und absolut Delphi typisch. Normale Interfaces in anderen Sprachen arbeiten absolut nicht so.
Soll heisen: man kann und darf sich eigentlich darauf nicht verlassen.

Desweiteren kann man sehr wohl dieses Verhalten zur Laufzeit dynamisch verändern. Man kann nämlich den VMT-Zeiger auf die VMT des Interfaces im "Datenbereich" des Objectes dynamisch verbiegen. Dieser VMT-Zeiger auf das Interface liegt so wie der VMT Zeiger auf die Klasse innerhalb des Datenbereiches des Objectes. Zb. Pointer(Self^) zeigt auf die VMT der Klasse. Und Pointer(Self + IAnyInterface.IOffset)^ zeigt auf die VMT des Interfaces.

Eine VMT eines Interfaces ist sehr simpel. Sie besteht immer aus mindestens 3 Zeigern auf die proceduren ._QueryInterface(), ._AddRef, ._Release. Danach kommen die durch das Interface zusätzlich deklarierten Methoden. Also so

Delphi-Quellcode:

type
  PMyVMT = ^TMyVMT;
  TMyVMT = packed record
    _QueryInterface: Pointer;
    _AddRef: Pointer;
    _Release: Pointer;

    AnOperationIntrocuedByMyInterface: Pointer;
  end;

Eine allozierte Interface-Variable sieht dann minimal so aus:

Delphi-Quellcode:

   PMyIntf = ^TMyIntf;
   TMyIntf = packed record
     VMT: PMyVMT;

     Field1: Integer;  
     Field2: Integer;
   end;

Exakt so sehen auch Objecte aus, und das ist ein Problem für die Entwickler bei Borland, denn nun müssen sie beide VMT's, die der Objecte und die der Interfaces in ein Object reinbekommen. Der Trick besteht nun darin das ein Object im Speicher aus einer "Kette" von solchen VMTs besteht. Als erste, ausgehende vom Pointer Self kommt das ursprüngliche Object mit seinem VMT zeiger zur Klasse und danach die einzelnen VMTs der verschiedenen impelemntierten Interfaces. Normalerweise sind diese nur die Zeiger auf die VMTs der Interfaces, also ohne zusätzliche Datenfelder.

Ein Object mit Interfaces sieht im Speicher also so aus:

Delphi-Quellcode:

  
type
  PMyObjectIntf = ^TMyObjectIntf;
  TMyObjectIntf = packed record
    VMT_Class: Pointer;  
    Field1: type;
    Field2: type;
   
    VMT_Interface1: Pointer;
    VMT_Interface2: Pointer;
    VMT_Interface3: Pointer;
  end;

Nun erklärt sich auch .IOffset, denn eine Interface Variable die auf ein Klassen implementiertes Interface in Delphi zeigt, zeigt im Grund mitten in den Speicherbereich des Objectes selber, also exakt an Addresse Self + IInterface1.IOffset.

Aber exakt das wird bei Interfaces anderer Programmiersprachen nicht so sein, und es stellt noch keinen Bezug auf die Klasse eines Objectes dar und es stellt auch NICHT sicher das die Reichenfolge und die .IOffsets bei ausschließlicher Kenntnis der Interface-Varibale von aussen berechnet werden können. Soll heisen, nur das implementierende Object selber hatt Zugriff auf seine Klassen-RTTI und kann die .IOffsets errechnen. Über einen normaler Interface-Zeiger geht dies nicht da die .IOffsets abhängig von der Klasse unterschiedlich sein können eben auch wenn verschiedene Klassen das gleiche Intrface implementieren.
Zwei Klassen, A und B implementieren das Interface C. Die VMT von C liegt aber in der Klasse A an einem ganz anderen IOffset als in Klasse B. Somit hat man eben keine Möglichkeit, von Aussen nur mit Hilfe einer Interface Variablen auf Self -> Self.ClassType -> Self.RTTI zu berechnen. In jedem Falle benötigt man dazu ein spezielles Interface das dann wie in meinem obigen Source den Interface-Zeiger umrechnet in einen Objectzeiger. Diese "Umrechnung" wird eben im Gegensatz zu anderen Programmiersprachen, durch den Delphi Compiler über die hardcoded erzeugten Dispatcher Funktionen erledigt.

WENN, man aber nun ein zusätzliches Interface zwingend benötigt, so kann man auch gleich den sauberen Weg wie oben angedeutet beschreiten.

Auf alle Fälle gilt: Da es zwischen einer Interface-Referenz keinen zwingenden Zusammenhang zum implementierenden Object gibt, kann man auch nicht Interface-Referenzen direkt in Object-referenzen umrechnen.

Gruß Hagen

[maximov]

Jungs, ihr seid gold wert

Da hab ich ja genau die richtigen erwischt, um diese oberflächlich simple frage zu diskutieren. Tut mir leid, dass ich erst jetzt von mir hören lassen. Ihr wisst ja wie das ist, wenn man viel zu tun hat ( ).

Da ihr ja hier ganze romane geschrieben habt, kann ich leider nicht auf alles eingehen, freue mich aber über die tiefe eurer diskussion. Finde man sollte solche diskusionen in eine gesonderte sparte verschieben, damit sie nicht zwischen dan ganzen 'wieso geht diese komponente nicht so wie ich will'-themen untergeht

Zum thema:

Ich bin dabei ein spezielles modell zu entwickeln, das nach aussen (für die view schicht) nur aus interfaces besteht. Dabei ist es notwendig, dass ich auch eines dieser interfaces zur identifikation nutzen kann. ZB. um über ein assozioativen array, andere objekte addressieren zu können. Um jetzt das gesuchte object zu finden, muss ich besprochene identität vergleichen können, was zunächst, überraschenderweisen, fehl schlug...

Zitat von choose:

Hallo Maximov,

wie Hagen bereits dargestellt hat, handelt es sich bei Schnittstellen (Interfaces) um unterschiedliche "Sichten" auf ein und dasselbe Objekt. Weil die Identität eines Objekts jedoch ein Wesensmerkmal darstellt, scheint es tatsächlich überaschend, dass der von Dir diskutierte Code bei einen Vergleich der Art

Delphi-Quellcode:

myObj := TMyClass.Create;
myRefToInterfaceA := myObj;
myRefToInterfaceBA := myObj;
Result := Pointer(myRefToInterfaceA) = Pointer(myRefToInterfaceB);

den Wert False zurückgibt.
...

genau...dann fiel mir natürlich auch ein, dass ein interface nur etwas über den zugriff auf ein objekt aussagt, aber leider nicht über das objekt selbst. Ínsofern habt ihr recht, wenn ihr sagt, dass ich mein konzept überdenken sollte (mach ich natürlich auch). Allerdings kommt es letztendlich auf das ergebnis an und ich wäre durchaus bereit einige annahmen zu akzeptieren, die 'typisch delphi' sind.

Zitat:

...
Was Du also machen kannst, wenn Du ohne "Identitätsinterface", wie Hagen es vorschlägt, an die Identität der Objekte zweier unterschiedlicher Interfaces herankommen möchtest, ist der Cast auf auf ein gemeinsames Interface, z.B. IInterface, und der anschließende Vergleich der Art
Result := (myRefToAnInterface as IInterface) = (myRefToAnotherInterface as IInterface)

Dies liefert bei mir, auf den ersten blick, sehr brauchbare ergebnisse und beantwortet im prinzip meine frage, da in meinem fall das eine interface von dem anderen erbt. Habt das aber noch nicht eingehend getestet.

Bei dieser möglichkeit, die ihr ja teilweise für problematisch haltet, werden im hintergrund nun einige sachen gemacht, unter anderem vermutlich auch _Addreff, _Release und QueryInterface. Da stellt sich mir natürlich die frage, ob die nutzung eines identitäts-interfaces nicht grundsätzlich schneller wäre? zumal auch komzeptionell sauberer.

Vielen dank vorerst!

[negaH]

Es wäre um die beiden Methoden Aufrufe .Object langsammer. Auch über das gemeinsamme Identität-Interface muß man ja vorher mit .QueryInterface() -> ala "as" das Identitäts-Interface anfordern. Das sollte aber im Grunde vernachlässigenbar sein. Soll heisen: der minimale Performanceunterschied zu ungunsten meiner Lösung sollte dich nicht weiter stören da die Methode einfach sauberer und besser wartbar ist für die Zukunft. Im Grunde fallen ca. 16 zusätzliche Assemblerbefehle an.

Vorrausgesetzt man benutz .QueryInterface() statt den "as" Operator. Der "as" Operator macht wesentlich mehr als .QueryIntrface(). Bei deinem Problem wäre der "as" Operator eh die schlechteste Wahl das dieser eben auch eine Exception auslösen wird wenn das Object das angeforderte Interface nicht enthält.

Du kannst aber in deinem Falle noch mehr an Performance rausholen. Deine Arrays[] auf die Interfaces sollten sortiert sein, und zwar binär nach .Object: TObject, so als wären es Cardinals. Wenn du nun in diesem Array[] nachschlagen willst ob ein Interface==Object schon vorhanden ist dann kannst du die Binäre Suche benutzen. Bei 1024 Einträgen im Array[] rufst du also maximal 12 mal die Methode .Object auf und weist danach a.) ob das Obhject/Interface schon im Array[] ist, und oder b.) an welcher Stelle im Array[] du es einfügen müsstest.

Somit wird die Frage wie schnell der Aufruf der Methode .Object: TObject ist, stark relativiert, weil du bessere Algorithmen benutzt.

Falls du aber diese Arrays[] sehr häufig aktualisieren musst, sprich es kommt sehr häufig vor das du neue Interface/Objecte dort einfügen und entfernen musst, dann sollte man dafür eine verlinkte Liste benutzen.

D.h. statt sich um 16 Taktzyklen mehr oder eniger Gedanken zu machen, solltest du die übergeordneten Algorithmen optimieren. Das bringt bei weitem mehr.

Beispiel, array mit 1024 Elementen, Aufrufe von .QueryInterface() 100 Taktzyklen, Aufruf von .Object +50 Taktzyklen

- binäre Suche -> 12 Aufrufe von .Object, macht 12 * 150 = 1800 Taktzyklen
- normale sequentiell Suche -> 513 Aufrufe von .Object durchschnitliche, macht 513 * 100 = 51300 Taktzyklen.

Wie man sieht selbst mit 50 Taktzyklen mehr bei der Benutzung von .Object + .QueryInterface ist das bei dem richtigen übergeordeneten und optimierten Algorithmus bei weitem effizienter als ein schlechter Algorithmus aber dafür nur .QueryInterface()

Fazit: halte den Code sauber und idiotensicher, optimiere besser andere Bereiche, wie zb. deine Ararys[], Listen etc.

Gruß Hagen

[choose]

Hallo Maximov,

wenn ich den Ursprung Deines Problems, das Verwenden einer Interfacereferenz als Schlüssel in einem Assoziativen Array (Dictionary) zu verwenden, richtig verstehe, könntest Du aus Performancegrunden die dafür gängige Variante des hashing verwenden.
Weil Du zu diesem Zweck einen Hashwert aus einem eineindeutigen Schlüssel (hier: unter Zuhilfenahme der Interfacereferenz), bilden, Du die Schlüssel letztlich vergleichen musst und in Deinem Dictionary letztlich nur solche Schlüssel zugelassen werden können, die diese Eigenschaft aufweisen, bietet sich Hagens Ansatz, ein zusätzliches Interface einzuführen, geradezu an!

Weil Schlüssel jedoch prinzipiell nicht unbedingt "gehasht" werden können müssen, könnte man die Interfaces für Dictionary und Hashtables selbst wieder voneinander erben lassen, etwa in der Art

Delphi-Quellcode:

type
  IIdentifiable = interface
    function GetIdentity: Cardinal;
    function IsSameTo(const AnIdentifiable: IIdentifiable): Boolean;
  end;
  
  IHashable = interface(IIdentifiable)
    function GetHashValue: Cardinal;
    function IsSameHashValueAs(const AHashable: IHashable): Boolean;
  end;

Ich hoffe, die ADTs

Delphi-Quellcode:

type
  TDictionary = class
     procedure Add(const AKey: IIdentifiable; const AnObject: TObject);
     procedure Remove(const AKey: IIdentifiable);
     function Has(const AKey: IIdentifiable): Boolean;
     function Get(const AKey: IIdentifiable): TObject;
     //..
  end;

  THashtable = class
     procedure Add(const AnObject: IHashable);
     procedure Remove(const AnObject: IHashable);
     function Has(const AnObject: IHashable): Boolean;
     //..
  end;

veranschaulichen, was ich meine.

[maximov]

Hashtables wären schon sinnvoll, wenn man nicht, so wie in meinem fall, von weniger als 64 elementen ausgeht. In den meisten fällen wohl eher < 16. Deshalb hab ich das jetzt schon in einer verketteten liste angeordnet, was wohl bei den stückzahlen am sinnvolsten sein wird.

Jetzt ist es auch so, dass der interface-type fest steht. Ich muss also nicht gegen beliebige interfaces prüfen. In meinem speziellen falle wäre also höchstens ein downcast nötig, womit der as-operator eigentlich zu viel des guten ist. Dh. ich könnte die identitäts-info auch in dieses interface aufnehmen und hätte somit die aller schnellste lösung, da ich lediglich zwei methoden aufrufen müsste.


Ich danke euch Daumen hoch.

[negaH]

16 Einträge, ist ja lächerlich
Nimm ein dynamisches Array of IInterface, und suche darin linear, fertig.

Hashtabellen, verlinkte Liste, sogar sortierte Arrays sind in diesem Falle zu große Kaliber und bringen keine wesentliche Performancesteigerung, benötigen aber garantiert mehr an Speicher als ein simples dynamisches Array.

Bedenke, ca. 4 Taktzyklen pro Assemblerbefehl auf einem 4 GHz Rechner sind 1.000.000.000 in Worten Eine Milliarde Assembleroperationen pro Sekunde. Da fallen die 16 Vergleichsoperationen nun wirklich nicht ins Gewicht.

Später, wenn dein Source/Programm all das komplizierte was du geplant hast auch richtig und zur vollsten Zufriedenheit erledigt, kannste dir immer noch überlegen ob du für die 16 Einträge in den Arrays bessere Algorithmen findest. Aber, ich vermute du wirst dann keinen Unteerschied in der Gesamtperformance erkennen können.

Gruß Hagen

PS: Ausnahme wäre eine verlinkte Liste der Interfaces untereinander. Diese verbrauchen im Vergleich zu einem Dynamischen Array ca. 12 Bytes weniger. Allerdings nur dann wenn es nicht zu viele Interfaces gibt die nicht verlinkt wurden. Denn diese Interfaces haben ja dann NIL Link auf das nächste Interfaces, verbrauchen also zusälich Speicher.

[maximov]

Ja, kann sein, das dies lächerlich ist. Aber von den listen wird es recht viele geben, dh. jedes kompositions-objekt hat eine solche liste, die beim traversieren gefunden werden muss und dann einen iterator für die eigentlichen kind-objekte liefert. Das ist jetzt aber auch egal, da es sich nur um eine machbarkeits-studie handelt und alle algorythmen und strukturen alterniert werden können, ohne das gesamtsystem zu beeinflussen dh. es wäre ein leichtes das ggf. auf dynArray, TList etc. umzubauen. Momentan hab ich das so implementiert, was auch funktioniert...

...aber gut, dass du dir sorgen machst