Supports(..) liefert Referenz welche AV auslöst

[Uwe Raabe]

Supports liefert dir im dritten Parameter einen Zeiger auf die VMT genau des Interfaces, das du abfragst. Da in diesem Fall die Typsicherheit nicht greift, da der Parameter typlos ist, musst du selbst dafür sorgen, daß die Interface-Variable dort auch den passenden Typ hat (nämlich den, den du abfragst).

[Sir Rufo]

Ihr müsst ja auch nicht gleich alle auf mir rumhacken

Dann versuch mal das hier

Delphi-Quellcode:

type
  IMyInterface = interface
    ['{88DDD9A5-F4BC-47B9-9240-31B1C986F230}']
    procedure doSomething( );
  end;

  TMyClass = class( TInterfacedObject, IInterface, IMyInterface ) // <- Augen auf
  public
    constructor Create( );
    procedure doSomething( );
  end;

procedure justSupportsThings( );
var
  myObject: TObject;
  myIntf: IMyInterface;
  castSuccessful: Boolean;
begin
  myObject := TMyClass.Create( );
  castSuccessful := Supports( myObject, IInterface, myIntf );
  if castSuccessful
  then
    myIntf.doSomething( ); // <- beim Eierkauf - Keine Exception mehr :o)
end;

[Stevie]

Hach ja, das alte Problem, dass "vererbte" Interfaces nicht implizit in der Klasse landen...

[Uwe Raabe]

Hier mal das Originalbeispiel etwas erweitert. Man vergleiche die Reihenfolge der Methodenaufrufe im Source mit der der tatsächlich ausgeführten Methoden.

Delphi-Quellcode:

program Project4;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.Classes;

type
  IMyInterface = interface
    ['{88DDD9A5-F4BC-47B9-9240-31B1C986F230}']
    procedure doSomething();
  end;

  IMyInterface2 = interface
    ['{D9B8FC6D-2F71-4E31-A5E7-0CCA98146E78}']
    procedure doSomeotherthing();
  end;

  TMyClass = class(TInterfacedPersistent, IMyInterface, IMyInterface2)
  public
    procedure doSomething();
    procedure doSomeotherthing();
  end;

procedure justSupportsThings();
var
  myObject: TObject;
  myIntf: IMyInterface;
  myIntf2: IMyInterface2;
begin
  myObject := TMyClass.Create();
  try
    if Supports(myObject, IMyInterface, myIntf) then
      myIntf.doSomething();

    if Supports(myObject, IMyInterface2, myIntf2) then
      myIntf2.doSomeotherthing();

    if Supports(myObject, IMyInterface2, myIntf) then
      myIntf.doSomething();

    if Supports(myObject, IMyInterface, myIntf2) then
      myIntf2.doSomeotherthing();

  finally
    myObject.Free;
  end;
end;

procedure TMyClass.doSomeotherthing;
begin
  Writeln('Someotherthing');
end;

procedure TMyClass.doSomething;
begin
  Writeln('Something');
end;

begin
  try
    justSupportsThings();
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  readln;

end.

[himitsu]

Zitat:

_AddRef(); // Damit mich das Supports(..) nicht abräumt

Da ist aber jemand selber Schuld!

Entweder man benutzt nur Interface-Referenzen oder nur Objekt-Referenzen.
Nur z.B. bei TComponent-Nachfahren kann man Beides benutzen, da dort die Referenzzählung deaktiviert wurde.

[Sir Rufo]

@himitsu

TInterfacedPersistent

Und man kann sich auch eine eigene Interfaced-Klasse bauen, die keine Referenzzählung hat.

[himitsu]

Sir Rufo:
Drum "z.B." ... halt Alles, wo die Referenzzählung nicht für die Freigabe benutzt wird.

@mjustin:
Nein, das Leak ist her nur, weil TComponent/TInterfacedObject nicht über die Referenzzählung freigegeben wird, sondern ausschließlich über das Free der Objektinstanz.
Das wurde absichtlich so gemacht, damit die Instanzen nur von der VCL verwaltet werden und man dennoch Interfaces benutzen kann (nur für Funktionszugriffe und nicht für die Freigabe).

Also bist DU an den Leak Schuld, denn du versuchst ein Interface über die Referenzzzählung freizugeben, welches darüber nicht freigegeben wird.

[mjustin]

Zitat von himitsu:

Nur z.B. bei TComponent-Nachfahren kann man Beides benutzen, da dort die Referenzzählung deaktiviert wurde.

Benutzen schon, aber eine Komponente einfach wie im folgenden Beispiel um ein Interface zu erweitern geht nur um den Preis von Memory Leaks. Der folgende Code erzeugt ein Leak einer Instanz von TMyImplementation:

Delphi-Quellcode:

program LeakTest;

uses
  Classes;

type
  MyInterface = interface
  end;

  TMyImplementation = class(TComponent, MyInterface)
  end;

  TMyContainer = class(TObject)
  private
    FInt: MyInterface;
  public
    property Impl: MyInterface read FInt write FInt;
  end;

var
  C: TMyContainer;
begin
  ReportMemoryLeaksOnShutdown := True;

  C := TMyContainer.Create;
  C.Impl := TMyImplementation.Create(nil);
  C.Free;
end.

Das Memory Leak ergibt sich nur bei TComponent als Basisklasse. Mit TInterfacedObject als Basisklasse wird das über Interface verwaltete Feld FInt beim Destroy mit freigegeben, und kein Leak bleibt zurück.

Unter Stackoverflow kann man den Hintergrund dieses Verhaltens detailliert nachlesen.
Why do interface implementations based on TComponent leak memory?