Interface referenzen auf gleichheit prüfen?

[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