Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Interfaces und nil setzen (https://www.delphipraxis.net/196595-interfaces-und-nil-setzen.html)

MyRealName 1. Jun 2018 20:40

Interfaces und nil setzen
 
Mal eine Frage, weil ich gerade so ein Problem hatte und es besser verstehen will...

Ich habe Frames und Datamodules, die interfaces haben. Frames werden dynamisch in ein Fenster-Bereich (Panel zum Bsp.) reingeladen und das form kennt das frame selbst nicht, nur das interface.
Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

ich habe aber wiederrum an anderen lokalen Stellen auch interfaces die ich nicht auf nil setze, aber die bereiten mir scheinbar keine Probleme.

Also, kann man es so zusammenfassen :

1. Interface globale variable : immer explizit auf nil setzen vor dem Programm ende, wenn das zugehörige Objekt freigegeben wird
2. Interface variable ist Klassenvariable : wenn die klasse zerstört wird, wird das interface freigegeben (ref counter runtergesetzt ?)
3. lokale Variable innerhalb einer procedure : wird auch dem stack angelegt und beim verlassen der procedure wieder der ref counter runtersetzt ?

Danke schonmal :)

Zacherl 1. Jun 2018 20:54

AW: Interfaces und nil setzen
 
Zitat:

Zitat von MyRealName (Beitrag 1403658)
1. Interface globale variable : immer explizit auf nil setzen vor dem Programm ende, wenn das zugehörige Objekt freigegeben wird
2. Interface variable ist Klassenvariable : wenn die klasse zerstört wird, wird das interface freigegeben (ref counter runtergesetzt ?)
3. lokale Variable innerhalb einer procedure : wird auch dem stack angelegt und beim verlassen der procedure wieder der ref counter runtersetzt ?

1. und 3. stimmen soweit (wobei Delphi Objekte nie auf dem Stack anlegt, aber dennoch automatisch das Interface Released, wenn es lokal war). 2. ist "glaube" ich nicht korrekt. Achso,
Delphi-Quellcode:
class var
, nicht Membervariable. Ne, dann trifft 2. ebenfalls zu.

MyRealName 1. Jun 2018 22:16

AW: Interfaces und nil setzen
 
nee, mit 2. meinte ich einen Member der Klasse wie :

Code:
type MyClass = class
     private
       IMyIntf : IMyInterface;
     end;

Schokohase 1. Jun 2018 22:59

AW: Interfaces und nil setzen
 
Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Zacherl 1. Jun 2018 23:19

AW: Interfaces und nil setzen
 
Zitat:

Zitat von Schokohase (Beitrag 1403666)
Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um
Delphi-Quellcode:
IInterface/TInterfacedObject
Nachkommen.

Zitat:

Zitat von MyRealName (Beitrag 1403663)
nee, mit 2. meinte ich einen Member der Klasse wie :

Code:
type MyClass = class
     private
       IMyIntf : IMyInterface;
     end;

Die sollten eigentlich nicht automatisch freigegeben werden.

Lemmy 1. Jun 2018 23:53

AW: Interfaces und nil setzen
 
Zitat:

Zitat von Zacherl (Beitrag 1403667)

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um
Delphi-Quellcode:
IInterface/TInterfacedObject
Nachkommen.

Tipp: Schau dir mal an was TInterfacedPersistent macht..

Schokohase 2. Jun 2018 00:21

AW: Interfaces und nil setzen
 
Zitat:

Zitat von Zacherl (Beitrag 1403667)
Zitat:

Zitat von Schokohase (Beitrag 1403666)
Dazu kann man pauschal eigentlich gar nichts sagen, denn ein Interface bedeutet nicht automatisch auch Referenzzählung.

Die Referenzzählung erfolgt in der konkreten Implementierung des Interfaces - oder eben nicht, je nach Implementierung.

Ein TDataModule, TForm ... bzw. alles was von TComponent abgeleitet ist, kann zwar mit Interfaces ausgestattet werden, kommen aber von Haus aus ohne Referenzzählung.

Was? Delphi (COM) Interfaces kommen alle von Haus aus mit Referenzzählung. Es geht hier um
Delphi-Quellcode:
IInterface/TInterfacedObject
Nachkommen.

Du hast insofern Recht, als dass immer die _AddRef/_Release Methoden aufgerufen werden.

Ob die implementierende Klasse damit etwas anfängt, hängt ... von der implementierenden Klasse ab.

TFrame, TDataModule, ... das hört nicht nach Nachfahren von TInterfacedObject an. Die leiten sich von TComponent ab und das kümmert sich um die Zählung und automatische Freigabe bei 0 Referenzen einen feuchten P...

Zacherl 2. Jun 2018 01:28

AW: Interfaces und nil setzen
 
Zitat:

Zitat von Schokohase (Beitrag 1403670)
TFrame, TDataModule, ... das hört nicht nach Nachfahren von TInterfacedObject an. Die leiten sich von TComponent ab und das kümmert sich um die Zählung und automatische Freigabe bei 0 Referenzen einen feuchten P...

Natürlich hast du Recht, dass man
Delphi-Quellcode:
_AddRef
und
Delphi-Quellcode:
_Release
selbstverständlich nicht in der "Standardform" implementieren muss und
Delphi-Quellcode:
TComponent
leitet diese Methoden einfach auf das unter
Delphi-Quellcode:
VCLComObject
hinterlegte Interface um (wenn vorhanden).

Aber in dem Falle wäre doch die komplette Frage obsolet bzw. das geschilderte Verhalten würde gar nicht auftreten. Die Freigabe von
Delphi-Quellcode:
TComponent
ist doch außerdem ganz strikt reguliert über das Ownership (
Delphi-Quellcode:
Owner
Property).

jaenicke 2. Jun 2018 06:20

AW: Interfaces und nil setzen
 
Zitat:

Zitat von MyRealName (Beitrag 1403658)
Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

Das hört sich so an als würde dein Datenmodul direkt das Interface implementieren. Davon würde ich abraten, wenn es so ist, da deine Interfacereferenz noch weiterleben kann, wenn das Objekt zerstört wurde (automatisch per Owner oder auch manuell).
Beim Programmende kommt aber die Deinitialisierung dieser Interfaces, aber wenn das Objekt dahinter schon zerstört wurde, knallt es ggf. beim Aufruf von _Release.

Wir haben das so gelöst, dass unsere visuellen Komponenten und Datenmodule lediglich durch ein Interface gesteuert werden. Wird das Objekt freigegeben, wird die Referenz darauf im Interfaceobjekt auf nil gesetzt, aber das Interfaceobjekt lebt weiter. Man kann nicht mehr viel damit machen, aber man kann dies sauber abfangen und prüfen. Und vor allem hat man noch alle Daten usw., da diese nicht in der visuellen Komponente stecken, sondern in einem weiteren Interface, das sowohl die visuelle Komponente als auch das Interfaceobjekt kennen.

MyRealName 2. Jun 2018 16:35

AW: Interfaces und nil setzen
 
Zitat:

Zitat von jaenicke (Beitrag 1403673)
Zitat:

Zitat von MyRealName (Beitrag 1403658)
Bei den Datamodules ist es so, dass die ein generelles programmweites interface zur Verfügung stellen, welches beim programmstart geladen wird.
Bei letzterem hatte ich zuletzt das Problem, dass ich dieses interface auf ein Datamodule für import/export beim start erzeugt wurde, aber nicht auf nil gesetzt am Ende. Das bereitete mir Probleme bei der unit-finalization. nachdem ich das IImportExport := nil eingebaut habe, ging es wieder.

Das hört sich so an als würde dein Datenmodul direkt das Interface implementieren. Davon würde ich abraten, wenn es so ist, da deine Interfacereferenz noch weiterleben kann, wenn das Objekt zerstört wurde (automatisch per Owner oder auch manuell).
Beim Programmende kommt aber die Deinitialisierung dieser Interfaces, aber wenn das Objekt dahinter schon zerstört wurde, knallt es ggf. beim Aufruf von _Release.

Wir haben das so gelöst, dass unsere visuellen Komponenten und Datenmodule lediglich durch ein Interface gesteuert werden. Wird das Objekt freigegeben, wird die Referenz darauf im Interfaceobjekt auf nil gesetzt, aber das Interfaceobjekt lebt weiter. Man kann nicht mehr viel damit machen, aber man kann dies sauber abfangen und prüfen. Und vor allem hat man noch alle Daten usw., da diese nicht in der visuellen Komponente stecken, sondern in einem weiteren Interface, das sowohl die visuelle Komponente als auch das Interfaceobjekt kennen.

IM Event Datamodule.OnCreate habe ich das interface gesetzt mit "Supports", aber durch unwissen im OnDestroy nicht entladen. Jetzt mache ich es und es fährt alles sauber runter wieder. Deswegen ja die Frage in welchen kombinationen man es manuell freigeben muss und wann nicht, um meinen Code nach möglichen problemen zu durchsuchen


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:39 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz