Interfaces in lokalen Variablen und deren Freigabe

[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.

[jaenicke]

Stimmt, da hast du Recht. Ich habe es nur laufen lassen und gar nicht genauer angeschaut. Die beiden Zeilen machen in der Reihenfolge natürlich keinen Sinn:

Delphi-Quellcode:

  intf := TMyInterfacedObject.Create( TObject(list) );
  list := TStringList.Create;

Richtig wäre:

Delphi-Quellcode:

  list := TStringList.Create;
  intf := TMyInterfacedObject.Create( TObject(list) );

Ach ja... hier gibt es übrigens eine bessere Lösung für dieses Problem:
https://blog.grijjy.com/2020/08/12/c...mart-pointers/

Denn die Herangehensweise aus dem obigen Beispielprojekt macht wenig Sinn, da man so z.B. bei asynchron ausgeführten anonymen Methoden Fehler bekommt, weil das Interface eigentlich gar nichts mit dem Objekt zu tun hat. Dann ist es sinnvoller das Objekt direkt freizugeben...

[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

[Uwe Raabe]

Durch die Verwendung von list in der Anonymen Methode wird die Instanz von list durch das Variable Binding intern verschoben und die in FObjectPtrs gespeicherte Referenz enthält ab dann ungültige Daten.

Man kann das schön im Debugger sehen: Außerhalb von TestAnonymProc kann er list nicht auflösen, innerhalb schon.

[jaenicke]

Zitat:

Zitat von swestner (Beitrag 1493913)

@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ß.

Ja, schon, aber wozu die Pointer? Eine Objektreferenz ist doch per se schon ein Pointer. Ein Pointer auf einen Pointer macht an der Stelle keinen Sinn.

Zitat:

Zitat von swestner (Beitrag 1493913)

Kann das nach dem gleichen Prinzip 2021 besser realisiert werden?

Ja, so wie ich es verlinkt habe. Smart Pointers ist das Stichwort. Die machen genau das, nur deutlich sinnvoller.