Hallo,
ich habe eine Funktion, wo ich ein Interface übergebe. Soweit so gut. Bevor ich es als Prameter übergebe habe ich eine Liste von Objekten die von meinem Interface und TInterfaceobject erben. Nun rufe ich meine Funktion auf die das Interface erwartet mit folgenden befehl
 if meineFunktion(meineListe[lindex] as myInterface) then .
Die Funktion läuft ohne Probleme durch. Am Ende der Funktion wird der Refcount, aber auf 0 gesetzt und mein Objekt wird freigeben. Warum wird mein Refcount auf 0 gesetzt, da mein Objekt nocht in meiner TObjectlist hinterlegt ist sollte der Refcount auf 1 bleiben. Wenn ich jetzt meine Liste mit Owned Objects freigebe fliegt es mir um die Ohren weil er versucht die Objekte freizugeben. Hat jemand eine Idee?


Gruß,
ngott2

Zitat von ngott2:

. Warum wird mein Refcount auf 0 gesetzt, da mein Objekt nocht in meiner TObjectlist hinterlegt ist sollte der Refcount auf 1 bleiben. Wenn ich jetzt meine Liste mit Owned Objects freigebe fliegt es mir um die Ohren weil er versucht die Objekte freizugeben. Hat jemand eine Idee?

"Geinterfacete" Objekte nur als Interfaces behandeln und nicht als Objekt anfassen (außer man weiß was man tut).
Erster Schritt: Aus der Objektlist entfernen. Wenn Listeneintrag gebraucht, dann mach dir eine TList<IDeinInterface>, in denen du die Interface-Referenz hältst.

Versuche dies:

markieren

Delphi-Quellcode:

var
 Tmp: myInterface;
begin
 ...
 Tmp := meineListe[lindex] as myInterface;
 if meineFunktion(Tmp) then
 ...

Zitat von mjustin:

Versuche dies:

markieren

Delphi-Quellcode:

var
 Tmp: myInterface;
begin
 ...
 Tmp := meineListe[lindex] as myInterface;
 if meineFunktion(Tmp) then
 ...

Wird nicht funktionieren, dann geht der Reference-Counter zwar nicht auf 0, wenn die Funktion endet, aber dafür dann, wenn tmp nicht mehr gebraucht wird.

Es gibt für das Problem zwei mögliche Lösungen:

1. Nicht das Objekt sondern ein Interface in der Liste speichern.
2. Die Implementation von _AddRef und _Release des Objekts ändern, so dass es kein Reference-Counting mehr durchführt (das macht z.B. TComponent so (oder war es bereits TPersistent?))
3. Absolut nicht zu emfpehlen: Den Reference-Counter direkt manipulieren. Nach der Erzeugung auf 1 setzen, vor dem Freigeben auf 0 setzen. (Ja, das ist ein Hack und wie gesagt nicht zu empfehlen.)

Hallo,
die Variable wurde auch als Const übergeben?

Zitat von hoika:

Hallo,
die Variable wurde auch als Const übergeben?

Ja übergebe ich als const.


Ich werde mal alles umbauen. Normalerweise arbeite ich auch immer mit den Interface, aber jemand anders hat die Basis geschrieben und leider nur mit Klassen gearbeitet.

Würde aber trotzdem gerne verstehen, wie Delphi das Intern macht. Weil wenn ich es mit ein Interface mache dann fügt er ja erst eine Referenz hinzu und löscht sie am Ende der Methode wieder. Warum funktioniert dies nicht gemischt Zwischen Interface und Klasse?

Zitat von ngott2:

Würde aber trotzdem gerne verstehen, wie Delphi das Intern macht. Weil wenn ich es mit ein Interface mache dann fügt er ja erst eine Referenz hinzu und löscht sie am Ende der Methode wieder. Warum funktioniert dies nicht gemischt Zwischen Interface und Klasse?

Wenn es kein Interface mehr auf die Instanz gibt wird gnadenlos abgeräumt, egal ob es noch einen Zeiger auf die Klasse gibt.

Ein "Mischbetrieb" sollte man nur im absoluten Notfall verwenden. Und dann funktioniert es nur wenn man explizit einmal _AddRef aufruft um die automatische Referenzzählung auszuhebeln.

Wenn man die Referenzzählung nicht will, darf man nicht von TInterfacedObject ableiten, sondern von TInterfacedPeristent .

@ngott2

Du darfst auch nicht folgendes machen:

zusammenfalten · markieren

Delphi-Quellcode:

procedure DoIt(Intf: IInterface);
begin
end;

...

DoIt(TMyClass.Create); // falsch!

...

var
tmpIntf: IInterface;
 
tmpIntf := TMyClass.Create;
DoIt(tmpIntf); // korrekt

In der ersten Variante kommt auch die Referenzzählung durcheinander.
Das ist etwas unschön und man muss das erst mal wissen.

Aber wenn man das beachtet, kann man damit schon vernünftig leben.

Ich arbeite inzwischen nur noch mit Interfaces und verstecke die Klassen hinter einer Factory. Dann kann man solche Probleme grundsätzlich ausschließen.