Klassen zur Laufzeit auf abstrakte Methoden überprüfen

[Sc0rpe]

Hallo Leute,

ich möchte gerne zur Laufzeit eine Liste aller Klassen erstellen, welche von einer bestimmten abstrakten Basisklasse ableiten.
Das kann ich bereits mithilfe der RTTI tun. Nun möchte ich aus dieser Liste später aber dynamisch eine Instanz erzeugen.
Deshalb sollten die Klassen in dieser Liste also nicht abstrakt sein, bzw. keine abstrakten Methoden haben.

Hier auf Stackoverflow habe ich schon eine Lösung dazu gefunden:
How to check if a Delphi class is declared abstract

Leider scheitert es bei mir an der Zeile

Code:

if GetVirtualMethod(c, i) = @_AbstractError then

Denn dazu heißt es

Code:

Unknown identifier _AbstractError

Obwohl ich klar und deutlich in der Datei System.pas die Deklaration und Definition von _AbstractError sehe.

Hat jemand eine Idee wieso? Denn es wundert mich schon, dass auf Stackoverflow niemand dieses Problem damit hatte.

btw: Ich habe die Frage auch hier gestellt: Check if a class has abstract functions

[himitsu]

Die System-Unit ist so ein bissl Eigen.

• mit diesen Bezeichner kommst du im Assembler an jene Adresse
• oder nimm dir eine Klasse, wo du weißt, dass sie es hat (TStrings), und hol dir die Adresse dort raus
• oder System.AbstractErrorProc :roll:

[Sc0rpe]

Hey Himitsu,

die Methode mit System.AbstractErrorProc funktioniert nicht, da diese natürlich eine andere Adresse liefert.

Über eine andere bekannte abstrakte Klasse an die Adresse zu kommen, würde zwar funktionieren ist aber m.M.n. nicht schönste Lösung.
Lieber wäre mir schon, wenn ich zuverlässig an die Adresse kommen könnte. Zumal die Lösung ja irgendwie funktionieren müsste, da Sie bereits auf Stackoverflow so veröffentlicht wurde. Da hat sich ja keiner beschwert, dass er nicht über _AbstractError an die Adresse kommt :| .

Was genau meinst du denn mit " mit diesen Bezeichner kommst du im Assembler an jene Adresse " ?

Grüße

[Uwe Raabe]

Zitat:

Zitat von Sc0rpe (Beitrag 1497245)

Zumal die Lösung ja irgendwie funktionieren müsste, da Sie bereits auf Stackoverflow so veröffentlicht wurde. Da hat sich ja keiner beschwert, dass er nicht über _AbstractError an die Adresse kommt :| .

Das könnte ja auch für eine ältere Delphi Version gelten, muss aber in neueren nicht zwingend auch so funktionieren.

[himitsu]

Zitat:

Zitat von Sc0rpe (Beitrag 1497245)

die Methode mit System.AbstractErrorProc funktioniert nicht, da diese natürlich eine andere Adresse liefert.

Sollte aber nicht.

Du hast doch aber nicht etwa auch dort ein @ davor gemacht? :stupid:

[Sc0rpe]

Zitat:

Zitat von himitsu (Beitrag 1497252)

Du hast doch aber nicht etwa auch dort ein @ davor gemacht? :stupid:

Doch natürlich. Wie sollte ich denn sonst die Adresse bekommen, um sie zu vergleichen?

Die unterschiedlichen Adressen machen ja auch Sinn, denn die unter AdressErrorProc angegebene Funktion wird ja in _AbstractError aufgerufen.

[himitsu]

Das ist bereits eine Adresse

und mit @ bekommst dann die Adresse von der Stelle, wo die Adresse steht, anstatt der Adresse selber. :stupid:

[Sc0rpe]

Ich stehe wohl etwas auf dem Schlauch.

Aber ich bekomme von

Code:

GetVirtualMethod(c, i)

einen Pointer zurück.
Wenn ich Versuche das mit AbstractErrorProc zu vergleichen, also

Code:

if GetVirtualMethod(c, i) = AbstractErrorProc

bekomme ich den Fehler: Incompatible Types
Mit @ davor kann ich es zwar kompilieren, aber bekomme wie gesagt eine andere Adresse.