Interfaces in lokalen Variablen und deren Freigabe

[generic]

Zu dem reference counting in Interfaces hab ich ein Video im Kanal:
https://www.youtube.com/watch?v=wrnyJW6dtgY

Wie Jänike schreibt mit "Result:=" gibst du Werte zurück.
Mit "exit" beendest du die aktuelle Funktion und der aktuell Result-Wert wird genutzt.

Das gilt bis Delphi 2009. Danach kann man das Result theoretisch auch im Exit setzen.
https://docwiki.embarcadero.com/Libr...en/System.Exit

Ich kann mir aber vorstellen, dass da vielleicht ein Bug drin ist, welcher die Referenzzählung durcheinander bringt.
Persönlich finde die Jänike Methode allerdings schöner als Exit(<Wert>);

[jaenicke]

Zitat von generic:

Ich kann mir aber vorstellen, dass da vielleicht ein Bug drin ist, welcher die Referenzzählung durcheinander bringt.

Das wäre kein Bug, sondern ein logisches Problem. Erzeugt man eine Instanz über den Konstruktor, erzeugt man eine Objektinstanz. Der Referenzzähler wird erst bei der Übergabe in eine Interfacereferenz erhöht. Packt man die Objektreferenz aber gar nicht in eine Interfacereferenz, sondern übergibt die Instanz direkt an eine konstante Methode, wird der Referenzzähler nirgends erhöht. Denn die aufgerufene Methode kann ja nicht wissen, dass der Referenzzähler dort erhöht werden muss. Denn durch das const wird das eigentlich gespart. Und der Konstruktur kann nicht wissen, dass er den Referenzzähler um eins erhöhen müsste, der hat ja auch gar nichts damit zu tun.

Der Compiler wiederum könnte zwar theoretisch mit Compilermagic ermitteln, dass dieses Problem an der Stelle besteht, und entsprechend den Referenzzähler korrigieren. Allerdings steht dem das Halteproblem entgegen. Der Compiler kann daher nicht zuverlässig feststellen, ob er an einer Stelle den Referenzzähler korrigieren muss oder nicht.

Und deshalb muss man Objektreferenzen stets in einer Variablen speichern um das Problem zu umgehen.

Bei Exit besteht das Problem aber nicht. Hier wird IntfCopy aufgerufen und entsprechend der Referenzzähler erhöht. Die bisherigen Angaben reichen daher nicht um das Problem nachzuvollziehen.

[swestner]

Hallo,

danke für die vielen Rückmeldungen.

Ich konnte das Problem jetzt im Rahmen eines Testprojekt reproduzieren. Das Projekt ist angehängt.

Das Problem ist die Verwendung des Objekts in der anonymen Methode in Verbindung mit dem Interface. Da geht was kaputt...

Code:

unit fMain;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TObjectPtr = ^TObject;

  IMyInterface = interface(IUnknown)
  end;

  TMyInterfacedObject = class(TInterfacedObject, IMyInterface)
  private var
    FObjectPtrs: array [0..0] of TObjectPtr;
  public
    constructor Create(var aObj: TObject);
    destructor Destroy; override;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
    procedure TestAnonymProc(aProc: TProc);
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TMyInterfacedObject }
constructor TMyInterfacedObject.Create(var aObj: TObject);
begin
  FObjectPtrs[0] := @TObject( aObj );
  TObject( aObj ) := nil;
end;

destructor TMyInterfacedObject.Destroy;
begin
  if Assigned( FObjectPtrs[0]^) then
  begin
    FObjectPtrs[0]^.Free;     // <== AV
    FObjectPtrs[0]^ := nil;
  end;
  inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  intf: IMyInterface;
  list: TStringList;
begin
  intf := TMyInterfacedObject.Create( TObject(list) );
  list := TStringList.Create;

  list.Add( 'Item1' );

  TestAnonymProc(
    procedure
    begin
      list.Add( 'Item2' )
    end
  );
  list.Add( 'Item3' );
end;

procedure TForm1.TestAnonymProc(aProc: TProc);
begin
  aProc();
end;

end.

Jetzt stellt sich die Frage: warum?

Grüße

Stefan

[Der schöne Günther]

Warum tust du dir das mit den Zeigern an?
Nimm eine TObjectList und gut ist - Du musst dich noch nicht einmal um die Freigabe der enthaltenen Objekte kümmern.

Siehe mein Beispiel im 2. Beitrag.

[swestner]

Wenn ich die TObjectList nehme löst das nicht das Problem, daß durch die anonyme Methode was kaputt geht....

[jaenicke]

Bei mir (aktuelle Community Edition) passiert kein Fehler.

Den Sinn der Pointer sehe ich aber auch nicht.

[Der schöne Günther]

Ich verstehe das überhaupt nicht, ich bin allerdings auch nicht so schlau.

Weshalb gibt man eine nicht initialisierte Referenz als var-Parameter in den Konstruktor, speichert sich den und drückt dann dort ein nil rein?

Du siehst doch schon in deinem Destruktor von TMyInterfacedObject dass da Schrott drinsteht und versuchst den dann freizugeben.

Das ist allerdings tatsächlich nur der Fall wenn die anonyme Methode im Spiel ist.

Die anonyme Methode "captured" deine lokale Variable "list". Die wandert dann irgendwie anderswo auf den Heap und der komische Trick mit den Zeigeradressen scheint nicht mehr zu funktionieren. Auch für den blöden Debugger ist die lokale Variable "list" unsichtbar.

[Uwe Raabe]

gelöscht

[swestner]

@jaenicke:
Ich denke, das Ganze macht doch Sinn...

Ziel des ganzen Konstrukts ist, daß ich nicht in jeder Methode alle dynamisch angelegten Variablen mit try..finally absichern muß.

Die Variable wird im VAR-Teil deklariert und dann der Pointer auf diese Variable in dem InterfaceObject gespeichert. Dabei spielt es keine Rolle, ob in der Variable schon was drin steht (Objekt) oder nicht.

Später wird dann der Variable ein Objekt zugewiesen.

Wenn die Methode verlassen wird, wird das Interface zerstört und dann werden im Destruktor alle Objekte in den lokalen Variablen zerstört.

Das funktioniert in unserem Programmcode tausende Mal so.

Haben wir übrigens nicht selbst erfunden sondern BoldSoft / Borland schon 2004.

Jetzt die Frage:
Kann das nach dem gleichen Prinzip 2021 besser realisiert werden?
Warum macht die anonyme Methode das "System" kaputt?

Stefan