Schnittstelle ohne COM-Eigenschaft

[Furtbichler]

Warum sollte man denn die Referenzzählung manipulieren wollen? Vergiss 'Free' einfach komplett. Verwende deine Objekte/Interfaces wie gewohnt, aber rufe niemals Free auf. Das brauchst Du nicht!

Wenn Du Objekte in einer Liste hältst und weißt genau, das Du das Element nicht mehr benötigt, dann entferne es aus der Liste.
Wenn Du ein globales Objekt freigeben willst, fang von vorne an (keine globalen Objekte) oder weise der Instanzvariablen einfach nil zu.

[Mikkey]

Zitat von r2c2:

Ja. Dafür sind die Methoden verantwortlich, die du von IUnknown erbst und in TInterfacedObject für dich implementiert sind.

TInterfacedObject kann ich nicht verwenden, weil ich bei den Klassen, für die es gedacht ist, nicht einfach eine neue Basisklasse unterziehen kann.

Zitat von r2c2:

Es gibt auch einen Hack über den du die Referenzzählung ausschalten kannst. Dazu musst du AFAIR den Referenzzähler im Konstruktor erhöhen. Somit wird der nie 0 und es verschwindet nix.

Im Code von TInterfacedObject steht nichts weiter als "dec(refCount); if refCount = 0 then Destroy; ". Da würde ich einen solchen Weg nicht wirklich als Hack sehen. Nach einem "CoCreateInstance" wird der Zähler schließlich auch mit 1 initialisiert und eine Klassenreferenz ist im weiteren Sinn auch eine Schnittstellenreferenz.

Zitat von r2c2:

Du kannst die Referenzzählung aber auch nutzen. Das programmiert sich dann so ähnlich wie die Smartpointer aus C++. Hab ich noch nicht gemacht, aber es gibt manche, die das wirklich mögen. Näheres zu Interfaces liest du z.B. bei Nick Hodges.

Es gibt Dinge, die mache ich nur, wenn etwas Anderes nicht praktikabel erscheint. In C/C++ und Delphi erzeugt man Klassenobjekte selbst. Es gibt keinen wirklichen Grund, sich da einer müllsammlerähnlichen Technik anzuvertrauen. COM hat seine eigenen Regeln, da kommt man nicht drumherum. In C# hat man ebenso keine andere Chance.

[Mikkey]

Zitat von Furtbichler:

Warum sollte man denn die Referenzzählung manipulieren wollen? Vergiss 'Free' einfach komplett. Verwende deine Objekte/Interfaces wie gewohnt, aber rufe niemals Free auf. Das brauchst Du nicht!

Es geht nicht um eine Neuprogrammierung. Es handelt sich um Klassen, die bereits existieren und die in einer bestehenden Anwendung angelegt und zerstört werden. Daran werde ich sicher nichts ändern.

Es geht nur darum, dass die bestehenden Objekte nach verschiedenen Aspekten "ähnlich" sind und bzgl. dieser Ähnlichkeit von einzelnen Methoden verwendet werden.

Beispiele (es geht nicht nur um visuelle Objekte):

Einstellungen von Formularelementen lassen sich per XML-Knoten konfigurieren oder können ihre Eigenschaften in einem XML-Knoten zurückliefern.

Formularelemente können Ausgang/Ziel einer Drag-and-Drop-Aktion sein.

Solche Dinge lassen sich viel besser handhaben, wenn man ein Objekt fragen kann, ob IIrgendwas unterstützt wird und dann IIrgendwas für die weitere Arbeit benutzt.

Die Referenzzählung ist dann zu nichts nütze und nichts weiter als lästig

[uligerhardt]

Zitat von Mikkey:

Die Referenzzählung ist dann zu nichts nütze und nichts weiter als lästig

Ich benutze da folgende Basisklasse:

Delphi-Quellcode:

type
  TPureInterfacedObject = class(TObject, IInterface)
  protected
    { IInterface }
    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

{ TPureInterfacedObject }

function TPureInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  Result := E_NOINTERFACE;
end;

function TPureInterfacedObject._AddRef: Integer;
begin
  Result := -1;
end;

function TPureInterfacedObject._Release: Integer;
begin
  Result := -1;
end;

Damit generiert der Compiler zwar immer noch Aufrufe für _AddRef und _Release, aber die töten das betroffene Objekt nicht.

[Mikkey]

Zitat von uligerhardt:

Damit generiert der Compiler ...

Jetzt ist das Brett weg, vielen Dank.

Wenn die Sachen vom Compiler übernommen werden, ist es zwar immer noch überflüssig, aber nicht mehr lästig, es stört dann nicht mehr so sehr.

Bei Klassen, unter denen ohnehin TInterfacedObject liegt, muss es bisher auch funktioniert haben, bei den anderen habe ich dadurch, dass ich _Release selbst implementieren muss, ohnehin die Kontrolle.