Re: Pointer to OVERLOADED member function?
On Feb 1, 7:04 pm, tragomaskhalos <dave.du.verg...@logicacmg.com>
wrote:
On Feb 1, 4:04 pm, "Somebody" <someb...@cox.net> wrote:
Allow me to explain further... I left out this part of the
explanation as it is OS specific...
Very:-).
* let there be a FOO.DLL (or FOO.LIB if compiling in static lib mode)
* let FOO.DLL / FOO.LIB contain a class called CFoo
* let CFoo contain a function called Foo() that has several overloads
including a static version
* The DLL / LIB is MFC, and one of the Foo() functions has a
bug which I am developing a workaround for. Foo() is not
virtual and while it can be patched in a derived class, I
need to trap all uses of Foo() -- some of which are not in
my control. I can't tell Microsoft to use my derived class
:).
* So, my class library already has some API hooking
functionality. I want to hook the CFoo::Foo() that has the
issue and fix it.
* To hook it, I need the exact address of CFoo::Foo() (ie a
void* pointer to the code). In other words, I can do this in
the DLL version by calling GetProcAddress(), but that'll
only work for the DLL version, and CFoo::Foo() is only
exported by ordinal (which can obviously change for every
binary version).
So, end result is that I need to get a pointer to the code,
so I can hook it with my API hooking functions.
If there is no overload, I can get the address of the code,
once an overload is introduced, the compiler can not resolve
the ambiguity.
It's still not clear whether you're interested in the static
Foo()s, or the member Foo()s, or both.
But going back to your original example with members, have
you tried:
void* extremely_dodgy_1 = reinterpret_cast<void*>(
static_cast<int (A::*)(int)>(&A::Test));
void* extremely_dodgy_2 = reinterpret_cast<void*>(
static_cast<int (A::*)()>(&A::Test));
Like James I can't see how a member function pointer
can usably be scrunched into a void* in this way, and
Comeau Online quite reasonably refuses to even
compile this code. However, since you're doing something
extremely grungy and OS-specific, and claim that it
"works" with your compiler in the non-overload case,
(again, I'm surprised it even compiles, but I'll take
your word for it) give it a go, bearing in mind that
my variables are very aptly named.
I'm not sure, but I have the impression that he really is trying
to intercept the function at its lowest level. He doesn't want
the address of the function, in the C++ sense, but the physical
address of the code which actually implements the function. And
since the machine he's running on doesn't use a Harvard
architecture, nor some sort of different segmentation model for
code and data, he probably can represent that in a void*
(although in many ways, a uint32_t would be more appropriate).
On the other hand, if that is his problem, there's nothing in
C++ per se to help him. He'll have to find out somehow how
pointer to member functions are implemented by his compiler, and
work from there to find the physical address. There will be
one somewhere, of course, because in the end, the function does
get called. But if the compiler uses trampolines of some sort,
he may have to do some dynamic disassembly. On the other hand,
if the function isn't virtual, there's a good chance that the
physical address is located somewhere in the pointer to member.
Where is, of course, another question.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34