Hi!

Bisher kam ich in Delphi immer ohne Interfaces aus, aber die Zeiten ändern sich und jetzt gibt's auch schon, gleich am Anfang, ein Problem:

Ich habe eine Klasse C, die ein Interface I realisiert. Erstelle ich nun eine Instanz Z dieser Klasse C, caste Z anschließend auf das Interface I (I(Z)), ist alles wunderbar.
Schreibe ich aber vor dem Cast Z in einen Pointer P (P vom Typ Pointer) und caste dann P auf das Interface I (I(P)), bekomme ich eine Zugriffsverletzung.
Und ich hab' keine Ahnung, warum. Ihr?

Einfaches Beispiel, denn ich fürchte, mit der obigen Beschreibung ist keinem geholfen:


Danke schonmal.

Conan

_________________
THE TRUTH IS NOT OUT THERE!

Hi,

auch wenn ich noch nie so wirklich mit Interfaces gearbeitet habe, glaube ich den Fehler zu sehen.
Da du den Pointer des TButton-Objekts nutzt, musst du vorher auch wieder auf diesen casten.
Heißt:


Alternativ könntest du auch direkt auf das Interface zeigen, brauchst halt nur noch eine var zum Interface.

Hat das denn überhaupt einen Zweck? Wozu einen Pointer auf b, wenn b doch schon ein Pointer ist? Oder bin ich grad auf dem Holzweg?

Ich denke auch, dass der Umweg über den Pointer an der Stelle den Compiler verwirrt und es genau deswegen zu einem Problem kommt. Aber das ganze ist alles viel zu kompliziert. Du kannst das Interface auch direkt zuweisen.

Folgendes ist vollkommen ausreichen. Bzw solltest du "Umwege" über Klassen auch in jedem Fall vermeiden.

Mein Fehler, ich hab' nicht gesagt, wozu ich's brauche:
Ich brauche es dummerweise genau so und in der Reihenfolge, wie ich es aufgeschrieben habe, denn ich habe eine Liste, in der Objekte aufbewahrt werden, die IDrawable realisieren. Diese Liste speichert die Information eben nur als Pointer. D.h. wenn ich ein neues Objekt hineinschreibe, dann kennt die Liste nicht den Typ des Objekts, außer, dass es IDrawable ist.
Um jetzt in der Liste auf jedes Objekt zugreifen zu können, will ich das Interface benutzen und dazu muss ich aus dem Pointer ein IDrawable machen.
Was ich allerdings noch machen könnte wäre, in der Liste keine Pointer, sondern IDrawables abzuspeichern. Das ist aber sehr umständlich, da es in Delphi keine Generics gibt und ich mir, wenn ich das richtig sehe, eine ganz neue Listenklasse nur für IDrawables schreiben müsste.
Mir fällt nur der Weg über den Pointer ein. Sehe ich das richtig? Ich hoffe, ich irre mich und ihr habt eine bessere Idee.
Aber schonmal vielen Dank für die Mühe.

Conan

_________________
THE TRUTH IS NOT OUT THERE!

Ich hab jetzt auch noch nicht oft mit Interfaces in Delphi gearbeitet, aber vielleicht ist TInterfaceList eher das richtige als eine Liste mit Pointern - unter anderem auch wegen dem Reference Counting bei Interfaces.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Ich hab noch nicht ganz verstanden, wo das Problem jetzt liegt.
Die oben auftretende Exception kann so umgangen werden:

Wenn du jetzt in der Liste noch andere Objekte als TButton hast, die von IDrawable abgeleitet sind und du trotzdem auf Render zugreifen muss, hast du imho einen Designfehler.
'In Objektlisten gehören nur Objekte desselben Typs'
Erstelle dazu ein Objekttyp welches von IDrawable abgeleitet ist und zB die Rendermethode als virtual; abstract; definiert.
Von diesem Objekttyp kannst du nun TButton ableiten und Render implementieren.

Diesem Objekttyp kannst du jetzt für die Klasse sichtbar machen und dann alle Objekte der Objektliste in dieses casten.

Noch schnell ein grobes Beispiel:


Auch wenn das Interface jetzt schon wieder unnötig ist, ich hoffe das war jetzt das Problem.

Du könntest anstatt den Pointer auf das Interface einfach eine Referenz auf das TObject speichern. Dann kannst du von da immer GetInterface mit der GUID deines Interfaces aufrufen. Solange du das nicht aus (anderssprachigen) DLLs importieren willst, sollte das seinen dienst tun.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Leider nicht, nein.
Deine Lösung funktioniert zwar, macht dabei aber Interfaces komplett unnötig.
Und in meinem Fall lässt sie sich leider nicht anwenden, da TButton ein Abkömmling der Liste ist, in die ich ihn reinpacke.
Somit müsste diese Liste den Typ ihres Abkömmlings kennen, der Abkömmling selbst muss aber natürlich den Typ seiner Mutterklasse kennen.
Das ergibt eine zirkuläre Referenz, die Delphi nicht gestattet, es sei denn, ich schreibe alles in eine Unit, was ich auf jeden Fall vermeiden will.



Ich weiß nicht genau, worauf du hinaus willst. Die Objekte sind alle selben Typs, insofern, dass sie alle das Interface IDrawable implementieren.
[sarkasmus]Wenn das ein Designfehler ist, dann ist meine Auffassung (und die vieler Professoren an meiner Uni) von Generalisierung grundlegend falsch[/sarkasmus]. Ich hoffe, es handelt sich hier nur um ein Missverständnis.

Mein Problem ist eigentlich ganz einfach formuliert:
Ist es denn nicht möglich, einen Pointer, der auf eine Instanz einer Klasse zeigt, auf ein Interface zu casten, das diese implementiert, ohne nochmal auf die Klasse selbst casten zu müssen?
Wenn es das nämlich nicht sein sollte, brauche ich gar nicht weiter nach Lösungen zu suchen.

Conan

_________________
THE TRUTH IS NOT OUT THERE!

Du bist mein Held. Nach einiger Rumprobiererei klappt's tatsächlich.
Vielen Dank!

Conan

_________________
THE TRUTH IS NOT OUT THERE!

Ich hatte das oben schon mal angedeutet. Allerdings will ich das gerade noch mal deutlicher sagen. Klasseninstanzen und Interface zu mischen ist keine gute Idee. Das wird mit großer wahrscheinlichkeit in Zugriffsverletzungen oder dreckigem Code enden. Denn Interfaces besitzen eine Referenzzählung. Diese Zählung sorgt dafür, dass die zu Grunde liegende Klasseninstanz gelöscht wird, wenn kein Interface mehr benutzt wird. Kleines Beispiel.

Bei der Zuweisung von Nil auf Drawable wurde die Instanz von TButton gelöscht. Anschließende Zugriffe benutzen ein Objekt welches nicht mehr existiert. Wenn man glück hat wurde der Speicher noch nicht verändert und es knallt nicht. Aber das ist dann nur Zufall. Es spielt auch keine Rolle ob die Klasseninstanz als Pointer in einer Liste liegt oder als direkt als TButton irgendwo in einer Variable. Die Instanz wird gelöscht. Es genügt in dem Fall auch die Methode zu verlassen, da Drawable eine lokale Variable ist würde die anschließend auch nicht mehr existieren und die Instanz würde gelöscht werden.
Man könnte das vielleicht durch rumschrauben an dem Referenzzähler hinbekommen, damit die Klasse nie sinnvoll gelöscht wird. Außer man macht das per Hand. Aber das ist sicher nicht Sinn und Zweck des Ganzen. Dadurch würde man sich nur potentielle Sicherheitslücken oder Speicherlöcher einfangen. Entsprechend kann ich nur dringenst davon abraten Klasseninstanzen und Interfaces zur gleichen Zeit benutzen zu wollen. Das gibt nur ärger. Hatten wir hier im Forum auch schon einige male.

Ich kann nur das Empfehlen was littleDave schon empfohlen hat. Das Objekt TInterfaceList bzw. IInterfaceList. Wenn ein Interface dort hinzugefügt wird, dann wird der Referenzzähler erhöht. Wird es gelöscht, dann wird er verringert. Das Auslesen funktioniert dann ähnlich wie Lord Horazont dann schon gesagt hat. In der Liste werden nur IInterface abgelegt und du musst dann dein Interface erfragen. Deine Interfaces benötigen dabei dann aber eine GUID (tastenkombi strg+shift+g).



[edit] PS: Du solltest bei so etwas auch FastMM benutzen. Beim Aufrufen von virtuellen Methoden von Klassen die gelöscht wurden schreit der kräftig auf. Dadurch finden man mitunter direkt Stellen die später irgendwann in sehr komischen Effekten enden.

Oh, das passt mir gar nicht.
Was ist, wenn ich statt TInterfacedObject einfach das TObject nehme und die Methoden aus IInterface selbst implementiere (und zwar leer)?
Dann gibt's kein Reference Counting und kein selbstständiges Löschen mehr.

Von diesem FastMM hab' ich noch nie gehört, aber ich hätte es schon oft sehr gut gebrauchen können. Danke!

Conan

_________________
THE TRUTH IS NOT OUT THERE!

Wieso prüft ihr vor dem "Knall"-Zugriff nicht einfach auf NIL? In der Java-Welt ist das prüfen auf NULL ein müßiges Allerlei das eine Menge vom Code bei Listen ausmacht.

_________________
(\__/)
(='.'=)
(")_(")

Evil-Devil: Versuchs mal. Wir sprechen uns dann wenns trotzdem knallt. Der Destruktor wird irgendwann intern aufgerufen. Dadurch wird doch der Pointer auf dem Stack oder in irgendwelchen Listen nicht gelöscht oder verändert. Wie soll das auch gehen. Entsprechend zeigt die Instanz dann irgendwo in den Speicher.

Conan: Ich muss gestehen ich weiß nicht ganz was du da vor hast. Willst du dann weiterhin die Interfaces benutzen oder alles auf eine klassische Objektstruktur umbasteln? Wenn Interfaces, dann weiß ich nicht ob das so ohne Weiteres klappt. Zu mal du auch so etwas wie QueryInterface implementieren musst. Allerdings stelle ich mir da auch die Frage was gegen TInterfaceList/IInterfaceList spricht? Die macht eigentlich genau das was du vor hast. Und die scheinst du gerade sehr erfolgreich zu ignorieren.

QueryInterface ist einfach gemacht, das ist nichts weiter als ein Aufruf von GetInterface und die Rückgabe von ... einem Fehlercode, wenns nicht klappt.
Ich habe für meine Projekte auch das ganze umgemünzt, weil ich mit dem automatischen Löschen der Objekte mal rein garnichts anfangen konnte. Die Holzhammermethode ist, beim erzeugen die Referenzzählung auf 1 zu setzen, aber dann muss man das in BeforeDestruction wieder um einen senken, sonst knallts (da gibts ne Prüfung).

Evil-Devil: Lossy sagts schon ziehmlich genau. Wenn du irgendwo Free aufrufst, sind ja nicht gleich alle Verweise auf das Objekt nil. Leider (oder auch gut so) .

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb