Problem mit 'nil' bei Objekten

[DSeven]

Hallo,

Ich habe folgendes etwas schwer zu beschreibendes Problem:
Undzwar habe ich mehrere Strategy's.
Über Strategy's kann man kurz gesagt funktionalität während der Laufzeit dynamisch ändern. Zum Beispiel Such algos.

Dieses Strategy's werden von IParserStrategy abgeleitet.
Ich füge die Strategy's dann in TList ein.
In meiner CodeBrowser Klasse habe ich eine Variable vom Typ IParserStrategy die immer die aktuelle Parser Strategy die verwendet werden soll aufnimmt.

Das problem liegt jetzt nur da, wenn eine Sprache z.B. SQL keinen Parser hat wird diese Variable auf nil gesetzt. Jetzt wird aber nicht nur die Variable auf nil gesetzt sondern auch das eigentliche IParserStrategy Objekt aus der TList. Es wird dann freigesetzt also der destrukor aufgerufen.

Wie kann ich das umgehen? In C++ ist das ja nicht so.
Falls ich es zu schwer erklärt habe bitte nochmal fragen.

cya

[Kedariodakon]

Erstellst du für jeden TList Eintrag einen neuen "Strategy's" oder benutzt du immer den selben???
Wenn du für jeden einen erstellst fügst du bestimmt so die sachen ein: addObject('222433254', @"Strategy's" ); richtig?
Wenn das so ist, lösch mal das "@"...

Wenn das jetzt alles müll war, da ichs net verstanden hab, was du tust, einfach ignorieren

Bye

[DSeven]

Em also ich füge zum Beispiel vier verschiedene IParserStrategy's ein. Und eigentlich wird immer das richtige Strategy ausgewählt. Aber wenn eine Sprache keins hat dann wird das vorherige Strategy einfach freigesetzt.

Strategy's werden in software Design Büchern gut erklärt. Also auf jeden fall einen blick wert.
Da Klassen und interfaces immer pointer sind ist

addObject('222433254', @Strategy );

equvalent zu

addObject('222433254', ParserStrategy);

Beides Zeiger beim ersten wird die Adresse übergeben und beim zweiten der Zeiger.
Bor Delphi ist ja schwerer als C++ warum wird es nicht wie in C++ gelöst.

cya

[mirage228]

Hi,

wenn Du einem Interface nil zuweist, wird (in Delphi) imho automatisch der Destruktor aufgerufen.

Ich würde Dir ansonsten noch empfehlen eine TInterfaceList zu verwenden, wenn Du mehrere Interfaces verwalten willst. Denn dazu ist diese gedacht.

mfG
mirage228

[DSeven]

Zitat von mirage228:

Hi,

wenn Du einem Interface nil zuweist, wird (in Delphi) imho automatisch der Destruktor aufgerufen.

mfG
mirage228

Jup ich weis deswegen frag ich ja nach einem lösungs ansatz.
Das nervt mich auch an delphi, warum wird es nicht so wie in c++ gemacht?

Zitat von mirage228:

Ich würde Dir ansonsten noch empfehlen eine TInterfaceList zu verwenden, wenn Du mehrere Interfaces verwalten willst. Denn dazu ist diese gedacht.

Hehe stimmt
Wieso funktioniert es jetzt auf einmal? Also jetzt gibts kein Problem wenn ich das Teil auf nil setzte das orignal in der Liste bleibt unbetroffen.
Würde nur zu gerne wissen warum? Schließlich will man auch die hintergründe verstehen.

[mirage228]

Hi,

also genau weiss ich das auch nicht.
Aber ich vermute, dass TInterfaceList die Referenzzählung handhabt, sodass das enstprechende Interface beim NIL setzen nicht freigegeben wird.

Aber mehr weiss ich auch nicht, habe mich noch nicht mit TInterfaceList beschäftigt

mfG
mirage228

[maximov]

Zitat von DSeven:

....Hehe stimmt
Wieso funktioniert es jetzt auf einmal? Also jetzt gibts kein Problem wenn ich das Teil auf nil setzte das orignal in der Liste bleibt unbetroffen.
Würde nur zu gerne wissen warum? Schließlich will man auch die hintergründe verstehen.

Naja, in delphi haben interfaces COM-pflicht und COM hat nunmal einen referenzCounter-muster (_AddRef und _Release). Wenn du deine strategie in eine normale liste einfügst, so passiert nix, bei einer intergefacesten liste wird _addRef aufgerufen und somit mitgeteilt, das noch eine referenz besteht, was dazu führt, das das objekt noch nicht freigegeben wird

[Robert_G]

Du kannst auch anstatt von TInterfacedObject abzuleiten, deine eigene Basisklasse entwickeln.
Den Krampf hatte ich mir mal angetan, da ich meinen Code nicht mit AddRefs zumüllen wollte. Auf die Art liegt es bei dir wann die Instanz zerstört wird.

[bttb930]

schau dir einfach mal die _AddRef- und _Release-Funktionen der Basisklassen an, dann dürftest Du das ganze leicht verstehen (Unit System):

Delphi-Quellcode:

function TInterfacedObject._AddRef: Integer;
begin
  Result := InterlockedIncrement(FRefCount);
end;

function TInterfacedObject._Release: Integer;
begin
  Result := InterlockedDecrement(FRefCount);
  if Result = 0 then
    Destroy;
end;

_Release ruft halt den Destruktor auf, wenn der interne Zähler 0 ist. Das ist fatal, weil das in vielen Fällen nicht heißt, dass das Objekt nicht mehr referenziert wird.

Man kann das umgehen, indem man eine eigene Klasse von TInterfacedObject ableitet und _Release überschreibt.

[NicoDE]

Wenn man weiss was man tut, kann man auch

Code:

Pointer(Foo) := nil;

verwenden.

(sollte man aber im Quelltext kommentieren, da man schnell wieder vergisst, warum man solche Hacks mal eben eingebaut hat... und meist gibt es eine saubere Lösung (nur halt nicht immer *g*)).

Zitat von DSeven:

Das nervt mich auch an delphi, warum wird es nicht so wie in c++ gemacht?

Weil es ziemlich nervt sich manuell um den Referenzzähler kümmern zu müssen.