Adressen von virtuellen und überladenen Funktion erhalten

FireFlow

Du bist auf einer ganz falschen Spur. Erklär mal was du damit anfangen willst.

Die tatsächliche Adresse der virtuellen Methode zu bekommen macht doch gar keinen Sinn, dann kannst du gleich das virtual weg lassen.

Konstruktor- und Destruktoradresse bekommst du nicht. Das geht nicht. Auf jeden Fall nicht laut dem C++-Standard, da kannst du machen was du willst. Das gibt auch gar keinen Sinn zu was brauchst du die?

Hier hast du deine Zauberfunktion:

template<typename T>T getAddress(T t) { return t; } //scnr

PS: Bin nun im Bett und das Forum ist mal wieder langsamer als der Doppelklick meiner Mutter

Gruß

Wozu willst du überhaupt die Adresse vom Konstruktor? Man erzeugt nie ein Objekt von dem man den Typ nicht kennt und wenn man den Typ kennt, kann man ja auch direkt den Konstruktor aufrufen.

Ich glaube du versucht gerade die Sprache zu vergewaltigen um deine Designfehler auszubügeln.

Neku

Dauert jetzt zu lange das zu erklären, hat was damit zu tun eine DLL für ein existierendes Programm zu coden dessen Code man nicht hat.

Ich suche eine Funktion/Macro, die die Adressen beliebige Funktionen und Methoden zurückgibt. Bisher mache ich das über ein Makro mit Assembler, da ich dann nur z.B. GetAddress (Klasse::Methode) machen muss. Leider kann ich auf die Art nicht die Adresse von überladenen Funktionen auslesen, da z.B. folgendes nicht möglich ist:

__asm mov eax, (void (CTest::*)())&CTest::FunktionD

@FireFlow: Deine getAddress-Funktion ist nichts anderes als die identische Funktion

7H3 N4C3R

Neku schrieb:

__asm mov eax, (void (CTest::*)())&CTest::FunktionD

Diese Zeile nicht sinnvoll. Ein Pointer-To-Member belegt üblicherweise 12-16 Bytes und kann somit sehr schlecht ins EAX-Register passen.

Auf Methoden/Funktionen eines Programms, welches du nicht kennst, kannst du nicht (sicher) zugreifen. Dazu fehlen dir Informationen. Z.B. welche Aufrufkonvention verwendet wird. Oder mit welchem Compiler das Programm übersetzt wurde und wie z.B. vtables im Speicher organisiert sind.

Im übrigen, &Klasse::Methode sollte niemals den virtuellen Mechanismus bemühen (wie auch - vtables existieren zwar pro Klasse, sind aber objektgebunden) sondern immer einen Zeiger auf die Methode der bezeichneten Klasse geben.

Neku

7H3 N4C3R schrieb:

Neku schrieb:
__asm mov eax, (void (CTest::*)())&CTest::FunktionD
Diese Zeile nicht sinnvoll. Ein Pointer-To-Member belegt üblicherweise 12-16 Bytes und kann somit sehr schlecht ins EAX-Register passen.

Wieso 12-16 Byte?
Mein Problem ist eher, dass der Cast-Operator hier nicht genutzt werden kann, und ich somit nicht bestimmen kann, welche der überladenen Methoden verwendet wird.

7H3 N4C3R schrieb:

Auf Methoden/Funktionen eines Programms, welches du nicht kennst, kannst du nicht (sicher) zugreifen. Dazu fehlen dir Informationen. Z.B. welche Aufrufkonvention verwendet wird. Oder mit welchem Compiler das Programm übersetzt wurde und wie z.B. vtables im Speicher organisiert sind.

Das Programm kenne ich schon, nur den Quellcode nicht.

7H3 N4C3R schrieb:

Im übrigen, &Klasse::Methode sollte niemals den virtuellen Mechanismus bemühen (wie auch - vtables existieren zwar pro Klasse, sind aber objektgebunden) sondern immer einen Zeiger auf die Methode der bezeichneten Klasse geben.

Ich möchte nur die Adresse der Methode, ob sie virtuell ist spielt dabei keine Rolle - der vtable ist in meinem Fall unwichtig.

Du hast echt keine Ahnung von was du überhaupt sprichst, gell?!
Die vtable ist für dich verdammt wichtig, wenn du virtuelle funktionen aufrufen willst...

Neku

Lies bitte erstmal den ganzen Thread. Ich habe nie davon geschrieben, dass ich die Methode aufrufen möchte...

CStoll

Neku schrieb:

Lies bitte erstmal den ganzen Thread. Ich habe nie davon geschrieben, dass ich die Methode aufrufen möchte...

Was willst du sonst mit den Funktionen machen?

[quote="LOLOLOLOL"]Du hast echt keine Ahnung von was du überhaupt sprichst, gell?!
quote]

ich habe das gefühl, er weiß allgemein nicht von was er redet!
er hat hier in einem thread auch schon gesagt, das es egal ist wo ein zeiger hinzeigt...

ich denk langsam, er isn troll...

Neku schrieb:

Lies bitte erstmal den ganzen Thread. Ich habe nie davon geschrieben, dass ich die Methode aufrufen möchte...

lies du dir nochmal paar tutorials durch...oben rechts in der ecke findest du einen link, da gibts viele gute anfängertutorials...

7H3 N4C3R

Neku schrieb:

Wieso 12-16 Byte?
Mein Problem ist eher, dass der Cast-Operator hier nicht genutzt werden kann, und ich somit nicht bestimmen kann, welche der überladenen Methoden verwendet wird.

Fang doch mal mit diesem Artikel hier an:
http://www.codeproject.com/cpp/FastDelegate.asp

Und lies insbesondere den Abschnitt "Member Function Pointers - why are they so complex?"

Neku

CStoll schrieb:

Neku schrieb:

Lies bitte erstmal den ganzen Thread. Ich habe nie davon geschrieben, dass ich die Methode aufrufen möchte...

Was willst du sonst mit den Funktionen machen?

Da ich zur Laufzeit per DLL in einem Programm Methoden durch eigene überschreibe brauche ich die Adresse, damit ich einen Sprung in den Speicher schreiben kann, wo sich die Originalmethode befindet. Da ich aber versuche, Funktionen, Methoden und Objekte möglichst genau zu rekonstruieren habe ich auch virtuelle Methoden.

Neku

Ich habe gestern erneut einen halben Tag damit verbracht, einen Weg zu suchen, die Adresse einer virtuellen Funktion unter g++ zu erhalten, wobei ich nun endlich Erfolg hatte!

Falls mal noch jemand wissen muss, wie das möglich ist:
Den Quellcode mit dem Argument "-Wno-pmf-conversions" kompilieren, sodass man problemlos &Klasse::VirtuelleMethode nach void* casten kann.

Wofür ich noch immer keine Lösung gefunden habe sind sind Konstruktoren und Destruktoren

Grüße,
Marc