Generisches Typecasting?

[Stevie]

Zitat:

Zitat von Muetze1

Ich habe dir doch nun schon versucht zu schreiben warum es nicht gehen kann, also in wie fern sollte es denn nun noch eine Lösung dazu geben?

Nun, es gibt in der RTTL doch die Möglichkeit dynamisch die published Elemente dynamisch auszulesen, gell?
Und für Libraries gibt es die Möglichkeit dynamisch irgendwelche Funktionen zu laden und auszuführen.
Dann könnte es doch auch möglich sein, anhand der Klasseninformation eine Funktion zu finden und auzuführen, oder?
Es ist ja schließlich auch möglich dynamisch irgendwelche Klassen zu erstellen, wenn sie registriert sind.

[maximov]

Ja, wenn die published sind ist das kein problem. Einfach den pointer holen und eine methoden-variable zusammen basteln:

Delphi-Quellcode:

type
  TMyCall = procedure of object;
var
  method:TMethod;
...
method.data := myObj;
method.code := myObj.MethodAddress('Perform');
...
if method.code <> nil then TMyCall(method); // dies ist der aufruf!

// edit: verdammte kommentare

[Muetze1]

Moin!

Zitat:

Zitat von Stevie

Nun, es gibt in der RTTL doch die Möglichkeit dynamisch die published Elemente dynamisch auszulesen, gell?

Mit den RTTI Informationen kannst du zur Laufzeit published Properties finden und "bearbeiten" - richtig. Bei deinem TypeCast müssten aber die RTTI Informationen Informationen für alle Methoden ausser private haben - die gibt es nicht und daher sind die Methoden schlecht zu finden in der Laufzeit.

Zitat:

Zitat von Stevie

Und für Libraries gibt es die Möglichkeit dynamisch irgendwelche Funktionen zu laden und auszuführen.

Die DLL's haben eine Tabelle wo der Name und/oder Index zu der Funktion drinne steht und anhand der Informationen wie auch die ganzen Relocation Informationen kann der Code Teil geladen, angepasst und ausgeführt werden. Diese Informationen fehlen einem auch hier wiederrum.

Zitat:

Zitat von Stevie

Dann könnte es doch auch möglich sein, anhand der Klasseninformation eine Funktion zu finden und auzuführen, oder?

Welche Klasseninformationen? Den Klassennamen kann man ja noch ohne Probleme rausfinden - da bietet dir ja TObject schon die Methode ClassName an, aber es werden keine Informationen vorgehalten über alle Methoden in der Klasse (bis auf die private Methoden) wie schon oben gesagt, daher hat man wenig Chancen. Und der Compiler wird bestimmt nicht über alle in dem Programm verwendeten Klassen eine Sprungtabelle aufbauen mit den Offsets zu alles möglichen Methoden und deren Namen.

Zitat:

Zitat von Stevie

Es ist ja schließlich auch möglich dynamisch irgendwelche Klassen zu erstellen, wenn sie registriert sind.

Das ist doch wieder was anderes: Dort wird doch nur eine MetaClass angelegt die die Klassen aufnehmen und somit könnten sie ja instanziiert werden. Das Problem ist hierbei aber das gleiche wie bei dir: Es können von den so instanziierten Instanzen nur die Methoden aufgerufen werden, die auch die Basis-Metaklasse auch kennt. D.h. wenn die Basis MetaKlasse von TObject stammt (Class Of TObject), dann kannst du dort kein Perform in den über den Weg instanziierten Instanzen aufrufen ohne Spezialisierung über einen speziellen (zur Compile Zeit schon definierten) TypeCast. Wenn du nun aber die Metaklasse vom Typ TWinControl aufbaust (Class Of TWinControl), dann kennen auch die Instanzen eine Methode Perform ohne Spezialisierung über einen direkten TypeCast. (Ich gehe davon aus, das Perform public ist ab TWinControl - dahingehend habe ich nicht nachgeschaut ob dem so ist).

Im Endeffekt ist es so, das bei allen deinen Beispielen extra dafür Vorkehrungen getroffen wurden damit dies möglich wird, nicht aber in dem Fall wo du die Informationen suchst.

@Maximov: Der o.g. Code sollte beim Aufruf eigentlich gut in die Hose gehen, da die Aufrufparameter fehlen und dadurch der Stack schiefer hängen sollte als der Haussegen.

MfG
Muetze1

[OregonGhost]

Zitat:

Zitat von Stevie

Wenn sie nicht vorhanden sind, ist der Fall klar, dann geht's sowieso nicht. Wenn sie aber in einer Nachfahrenklasse überschrieben wurden, dann kommt diese Methode überhaupt nicht zum Zuge, sondern die in TWinControl. Deshalb das TypeCasting, damit mit der "richtigen" Klasse gearbeitet wird.

Moment. Drehen meine OOP-Kenntnisse jetzt durch oder was ist los? Wozu gibt's Polymorphie? Damit ich einen Basisklassenzeiger (oder halt eine Referenz) wie TWinControl habe, dessen Methode aufrufe und trotzdem die Methode der Klasse, aus der das Objekt letztendlich instanziiert wurde (wie TEdit), ausgeführt wird. Oder nicht? Wo ist das Problem? Es wird doch immer die überschriebene Methode ausgeführt.
Denn du erkennst ja schon, das das nicht funktioniert, wenn die Funktion nicht in der Basisklasse enthalten ist, folglich beziehst du dich schon auf die Polymorphie (denn ohne Polymorphie bist du nicht daran gebunden, was du von wem aufrufst).

Oder ist das jetzt ein Denkfehler meinerseits und du willst was ganz anderes? :gruebel:

[Stevie]

So'n Mist!!! :evil: Aber danke für die eingehene Erklärung, hab mir das wohl zu einfach vorgestellt. :roll:
Aber mal angenommen, eine von TWinControl abgeleitete Klasse hat eine Methode published gemacht, kann ich dann das von maximov gepostete Beispiel anwenden?

Nachtrag:
Tja, ich hab eben gedacht, ich könnte genau sowas wie Polymorphie benutzen, obwohl die Methoden überhaupt als polymorph deklariert sind... :pale:

[maximov]

Zitat:

Zitat von Muetze1

Moin!

...
@Maximov: Der o.g. Code sollte beim Aufruf eigentlich gut in die Hose gehen, da die Aufrufparameter fehlen und dadurch der Stack schiefer hängen sollte als der Haussegen.

MfG
Muetze1

Jeder, der so etwas macht ist selbst dafür verantwortlich, das die methode die richtigen parameter erhält :shock: ...is nicht ganz eifach das zur laufzeit zu entscheiden, da keinerlei infos über die signatur der methoden vorliegen, aber wenn man sich ein paar konventionen aufstellt kann man das vertreten.

..

Wie auch immer. Ich würd auch eher auf Polymorphie zurück greifen.

[Phoenix]

Zitat:

Zitat von OregonGhost

Moment. Drehen meine OOP-Kenntnisse jetzt durch oder was ist los? Wozu gibt's Polymorphie? Damit ich einen Basisklassenzeiger (oder halt eine Referenz) wie TWinControl habe, dessen Methode aufrufe und trotzdem die Methode der Klasse, aus der das Objekt letztendlich instanziiert wurde (wie TEdit), ausgeführt wird. Oder nicht? Wo ist das Problem? Es wird doch immer die überschriebene Methode ausgeführt.
...
Oder ist das jetzt ein Denkfehler meinerseits und du willst was ganz anderes? :gruebel:

Letzteres.

Du hast folgendes Problem:
Du hast ein TButton, der aber als TWinControl gecastet ist.
Der Compiler geht also innerhalb der Methode davon aus, das Du nur ein TWinControl hast. Wird in diesem Moment eine Methode aufgerufen wie z.B. Repaint setzt der Compiler die Sprungadresse zu TWinControl.Repaint ein. Da hilft das nichts, das Dein Objekt ein TButton ist und Repaint dortdrin eigentlich überschrieben wäre, da das der Compiler der die Sprungadresse dorthin compiliert nix davon weiss.

Du musst tatsächlich TButton(Object).Repaint aufrufen um die überschriebene Methode zu nehmen.

[maximov]

Zitat:

Zitat von Phoenix

...

Letzteres.

Du hast folgendes Problem:
Du hast ein TButton, der aber als TWinControl gecastet ist.
Der Compiler geht also innerhalb der Methode davon aus, das Du nur ein TWinControl hast. Wird in diesem Moment eine Methode aufgerufen wie z.B. Repaint setzt der Compiler die Sprungadresse zu TWinControl.Repaint ein. Da hilft das nichts, das Dein Objekt ein TButton ist und Repaint dortdrin eigentlich überschrieben wäre, da das der Compiler der die Sprungadresse dorthin compiliert nix davon weiss.

Du musst tatsächlich TButton(Object).Repaint aufrufen um die überschriebene Methode zu nehmen.

Denk da nochmal drüber nach! Entweder hast du dir ein schlechtes beispiel gesucht oder Polymorphy nicht verstanden (nicht böse sein). ABER selbstverständlich wird in diesem fall TButton.Repaint aufgerufen, denn sie wurde ja explizit von TButton überschrieben.

ODer wie darf ich dich verstehen?

[Muetze1]

Moin!

Nein, da er in die VMT Tabelle ausgehend von der aktuellen Instanzenadresse reinspringt, springt er an die Position der RePaint Procedure die der Button aber in der Instanz mit seiner eigenen Adresse überschrieben hat. Er wird bei dem Vorgehen trotzdem das Repaint des Buttons aufrufen.

Probiere es aus!

MfG
Muetze1