Refcount meines Objektes geht zu früh auf 0

[ngott2]

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

Delphi-Quellcode:

 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

[TiGü]

Zitat:

Zitat von ngott2 (Beitrag 1416464)

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

[mjustin]

Versuche dies:

Delphi-Quellcode:

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

[dummzeuch]

Zitat:

Zitat von mjustin (Beitrag 1416475)

Versuche dies:

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.

[dummzeuch]

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

[hoika]

Hallo,
die Variable wurde auch als Const übergeben?

[ngott2]

Zitat:

Zitat von hoika (Beitrag 1416524)

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?

[Bernhard Geyer]

Zitat:

Zitat von ngott2 (Beitrag 1416540)

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.

[Uwe Raabe]

Wenn man die Referenzzählung nicht will, darf man nicht von

Delphi-Quellcode:

TInterfacedObject

ableiten, sondern von

Delphi-Quellcode:

TInterfacedPeristent

.

[stahli]

@ngott2

Du darfst auch nicht folgendes machen:

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.

[Schokohase]

Zitat:

Zitat von stahli (Beitrag 1416545)

Du darfst auch nicht folgendes machen:

Delphi-Quellcode:

procedure DoIt(Intf: IInterface);
begin
end;

...

DoIt(TMyClass.Create); // falsch!

In der ersten Variante kommt auch die Referenzzählung durcheinander.

Nein, kommt sie nicht. Das ist kein Problem

[dummzeuch]

Zitat:

Zitat von Schokohase (Beitrag 1416551)

Zitat:

Zitat von stahli (Beitrag 1416545)

Du darfst auch nicht folgendes machen:

Delphi-Quellcode:

procedure DoIt(Intf: IInterface);
begin
end;

...

DoIt(TMyClass.Create); // falsch!

In der ersten Variante kommt auch die Referenzzählung durcheinander.

Nein, kommt sie nicht. Das ist kein Problem

Doch, es gab Compiler-Versionen, bei denen das schief ging. Ich bin mir allerdings gerade unsicher, ob das mit oder ohne const-Parameter war. Eines von beiden schlug fehl.

[Schokohase]

Zitat:

Zitat von dummzeuch (Beitrag 1416557)

Zitat:

Zitat von Schokohase (Beitrag 1416551)

Zitat:

Zitat von stahli (Beitrag 1416545)

Du darfst auch nicht folgendes machen:

Delphi-Quellcode:

procedure DoIt(Intf: IInterface);
begin
end;

...

DoIt(TMyClass.Create); // falsch!

In der ersten Variante kommt auch die Referenzzählung durcheinander.

Nein, kommt sie nicht. Das ist kein Problem

Doch, es gab Compiler-Versionen, bei denen das schief ging. Ich bin mir allerdings gerade unsicher, ob das mit oder ohne const-Parameter war. Eines von beiden schlug fehl.

Ja, wenn die Methode so definiert ist

Delphi-Quellcode:

procedure DoIt(const Intf: IInterface);
begin
end;

dann wird der RefCount nicht erhöht und man hat bei

Delphi-Quellcode:

DoIt(TMyClass.Create);

ein Mem-Leak. Das ist auch heute noch so.

[stahli]

Ok, solche Feinheiten hatte ich jetzt nicht mehr auf dem Zettel.
M.E. ist es immer sinnvoll, solche Konstrukte generell zu vermeiden (statt für jede Compilerversion und Parameter-Signatur zu prüfen, ob diese unter den Problemfall fällt oder nicht).

[Schokohase]

Zitat:

Zitat von stahli (Beitrag 1416562)

Ok, solche Feinheiten hatte ich jetzt nicht mehr auf dem Zettel.
M.E. ist es immer sinnvoll, solche Konstrukte generell zu vermeiden (statt für jede Compilerversion und Parameter-Signatur zu prüfen, ob diese unter den Problemfall fällt oder nicht).

Es ist der

Delphi-Quellcode:

const

Parameter der den Unterschied macht, nicht die Compiler-Version, denn das Verhalten ist bei allen gleich.