Darf ich das?? Wenn nein irgendwelche Tipps wie ich das umgehen könnte??

Ja ich darf das XD habe gerade festgestellt, dass das Problem an einer anderen Stelle lag und jetzt läuft alles wieder einwandfrei...

Dürfen tust du das sicherlich. Nur mir stellt sich die Frage ob du das auch tun solltest? Die Methode Update ist virtuell abstrakt und in der abgelitten Klasse auch schön überschrieben. Damit wird beim Aufruf die Methode die der abgelitten Klasse aufgerufen. Der klassische Weg mit dem Umgang von abstrakten Klassen zum Implementieren von variablen Codeteilen. So weit so gut. Nichts desto trotz halte ich die generelle vorhensweise für potentiell sehr gefährlich. Warum? Das Interface. TInterfacedObject implementiert eine Referenzzählung. Diese Zählung löscht deine Klasseninstanz sobald der Zähler 0 ist. Allerdings werden dort nur Interfacepointer gezählt. Also wenn du 20 Pointer auf die Klasseninstanz hast, dann ist der Zähler trotzdem 0. Sobald du jetzt ein mal ein Interface von der Klasse anforderst und das Interface wieder wegschmeißt, dann wird deine Klasseninstanz gelöscht. Ob du willst oder nicht. Und das schönste daran. Du merkst davon erst etwas, wenn du das nächste Mal auf dein bereits gelöschtes Objekt wieder zugreifen möchtest. Und das vermutlich nur, weil es dann zu einer Zugriffsverletzung kommt.

Dieses Problem hab ich bereits bedacht und gelöst idem ich den Referentzähler im Constructor um 1 erhöhe und im Destructor entsprechend um 1 verringere dies hat die Folge, dass es erst dann wenn es auch soll freigegeben wird.

moin, kann mir das jemand mit dem Referenzzähler genauer erklären? Ich mach das mit den Interfaces nähmlich genaus so, hab aber bisher keine Fehler bekommen, evtl. aus Zufall, da würde ich gerne wissen wie das genau zu Stande kommt.

Danke schonmal und Grüße!

_________________
Klar Soweit?

In dem Code FrenK stecken zwar Interfaces aber die werden nicht aktiv benutzt. Von daher könnte man sie eigentlich auch fast weglassen. Außer für eventuelle Mehrfachvererbung.

Aber Beispiel von dem was ich meinte.

Ein Interface und die dazugehörende Klasse. Was das Interface an funktionen anbietet ist für das Beispiel vollkommen egal.


Ein Beispiel wie Interfaces verwendet werden.


Normal erzeugt man eine Klasse und weißt diese auf eine Interfacevariable zu. Damit kennt blah nur noch die Funktionen die das Interface zur Verfügung stellt. Eventuelle andere Interfaces (Mehrfachvererbung) lassen sich entweder per Operator AS oder per Blah.QueryInterface zurückgeben. Es ist auch möglich eine Variable von TBlah zu erzeugen und dann die Variable auf die Interfacevariable zuzuweisen.

In jedem Fall wird aber bei der Zuweisung auf eine Interfacevariable intern _AddRef aufgerufen. Also die Klasseninstanz wird ein mal mehr verwendet. Erstellen wir noch eine zweite Interfacevariable, dann ein zweites mal. Usw. Wenn wir dann auf eine Variable nil zuweisen oder die Methode verlassen, dann wird _Release aufgerufen. Und der Zähler verringert. Ist der Zähler 0 wird innerhalb von _Release der Destruktor aufgerufen. Damit ist die Instanz weg.



Diese Zählung arbeitet nur mit dem Interfaceteil der Klasse zusammen. Variablen vom Typen TBlah werden nicht gezählt. Und dann kann es passieren, dass durch die Interfaces die Klasse einem unter dem Hinter weggelöscht wird. Das aber wiederrum bekommt man nicht mit. Die Instanz der Klasse sieht vollkommen okay. Eventuell existierende Pointer auf die Instanz sind nach wie vor vorhanden und enthalten noch den Pointer an der die Klassendaten mal lagen. Also so etwas wie Assigned wird sagen, dass alles okay ist. Vergleichbar wäre das in etwa auch wie folgt.


Wobei man da nicht mal die Instanz wegseln müsste. Es reicht auch, wenn man Blah_1 nicht nil setzen würde. Der Effekt ist in allen Fällen der Gleiche.

PS: Das Kawumm oder die Zugriffsfehler müssen aber nicht immer auftreten. Die Klassen sind recht doof. Eine Klasseninstanz besteht nur aus einem Pointer auf Code und einem Pointer auf die Daten. Wenn die Daten freigegeben werden, dann bleibt der Wert an dieser Speicherstelle meistens noch gleich. Wenn man dann mit einer ungültigen Klasseninstanz auf Member zugreift, dann greift sie auf den freigegebenen Speicher zu. Dort stehen aber noch richtige Werte. Also passiert nichts schlimmes. Nur sobald jemand anderes Speicher haben will und sich die Bereiche überschneiden können echt lustige Dinge entstehen. Alternativ kann es auch passieren, dass der Speichermanager den Speicherblock komplett wieder an das Betriebsystem übergibt. Dann knallt es recht zuverlässig. (Invalid Pointer operation etc.) Also es muss nicht zwingend knallen. Wenn man Glück hat kann man noch eine halbe Stunde mit der Instanz weiterarbeitet ohne, dass was passiert. Das sind dann aber Fehler die besonders Heimtückisch sind.

PPS: Wenn ich neben dem Interface noch die Klasseninstanz benötige, dann würde mal ich persönlich mal stark überlegen ob Interfaces wirklich nötig sind und ob man das nicht eventuell durch eine reine Klassenstruktur lösen kann. Die richtige Struktur zu finden ist ja das schwierigste an OOP. Interfaces sehe ich eher nur da wo man die Schnittstelle von der Implementation trennen muss. Also wäre es möglich 2 komplette getrennte Klassenhirarchien zu machen die beide ein Interface anbieten womit man auf diverse Eigenschaften zugreifen kann. Dann würde man auskommen, wenn man das Interface benutzt. Alles andere wäre dann egal. Was aber im Endeffekt wieder nichts weiter als eine abstrakt Basisklasse ist. Nur eben kann eine Klasse mehrere Interfaces anbieten. Darf aber nur eine Basisklasse haben.

Also wenn ich das jetzt richtig verstanden habe, dann wird nur beim instanzieren eines Interfaces der RefCount inkrementiert, nicht beim instanzieren einer Klasse. Klingt irgendwie logisch.. oder so !? Auf der anderen Seite mus ich aber auch gestehen, das mir das Konstrukt, welches ich mit der Interface/Klassen kombination geschaffen habe selbst merkwürdig vorkommt und im nachhinein festgestellt habe, das ich das Interface garnicht gebraucht hätte.

_________________
Klar Soweit?

Richtig ich brauche das ganze für Mehrfachvererbung und dachte eben es könnte zu Problemen kommen wenn ich eine klasse von TInterfacedObject ableite, aber erst ein Nachfahre dieser Klasse benutzt eben Interfaces. Das eigene Problem lag daran, dass ich einen Pointer vergessen habe entsprechen zu incrementieren aber das hat sich ja wie bereits gesagt geklärt.

Um auf den Referentzzähler zurückzukommen ich hab bis jetzt 2 mögliche ansätze dieses Problem zu umgehen gefunden zum einen ein eigener Zähler zum anderen Manipulation des Zählers.

Ist das ein delphispezifisches Problem? Ich hab bei Java viel mit Interfaces zu tun, und nie Probleme damit. Im Gegenteil, ich liebe diese Idee.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das ist kein Problem. Das ist von der Klasse TInterfacedObject so gewollt. Es geht bei Interfaces ja auch um solch eine Referenzzählung. Denn die werden benutzt und bei nicht mehr gebrauchen räumen sie sich selber weg. So wie das sein soll. Nur wenn man andere Teile dort mit einbezieht kanns Probleme geben.

Im übrigen muss man nicht InterfacedObject benutzen. InterfacedObject implementiert nur die 3 Methoden die für Interfaces benötigt werden. Also da könnte man auch eine Basis implementieren die ohne Zählung auskommt. Weil das ist ja eigentlich auch genau das was du jetzt so auch machst. Was aber eigentlich auch keine große Rolle spielt.