You must, of course, cast the pointer to the appropriate pointer-to-function type before calling it. Furthermore, you cannot do this with pointers-to-member-functions.

Quote:Original post by King of Men
can I jump to that address in memory and continue execution?

If you wanted to be clever(/evil) about it, and didn't mind getting your hands dirty with a little assembly, you could replace the stack pointer with the given address. There are a few registers that you'll need to update besides just the stack pointer, though (exactly which ones will vary, but the instruction pointer will need to be changed, for one).

Bruce Dawson discussed such a system for implementing micro-threads in Game Programming Gems 2 (read it here).

Strictly speaking, you don't need to cast the pointer to the correct type. You can cast it to whatever you feel like and call away. Chances are your app will crash very soon after that call and you'll be left looking at some disassembly trying to work out what the correct signature is. Hey, if all else fails you could (in x86) just do something like



Good luck with that! ;-)

Quote:Original post by King of Men
Oops, I didn't specify the problem completely. I should have added "without knowing the function signature at compile time".

Do you know the "set of possible signatures" at compile time? And can you figure out the one to use at run-time prior to invocation?

The ability to generically invoke nearly any function dynamically is done all the time in frameworks / libraries. But just like and factory / serialization or downcasting interface scenerio ... something has to exist to manage the decisions and some data must be provided to drive the choice of which to use.

For instance you can have an abstract class like InvokableMethodType that you derive from for each signature you want to support. Each derived class can register their existence with the base class, preferably including information like an ID / GUID and some friendlier name. Then something like your game scripting language could do:

Invoke(FunctionVoidIntInt,PlotPixel,1.0,2.0)

which your engine could process as ... A) look up the invocation class "FunctionVoidIntInt" in the type / signature manager. Then lookup up the method address for PlotPixel stored probably in another manager. Then invoke it with the 2 arguments given (after casting to type).

Of course this system can be as simply or complex as needed.

Dropping to assembly would not solve the problem of having to know the types and signatures involved, really. In fact (having done it) it's probably going to result in more management.