Dynamic function calling

[Skillless]

Alright, what im trying to achieve is to call a function dynamically,

Heres the example;

#include <windows.h>

int main()
{
    char* parameters[10];
    WriteParametersForAFunctionInADllIntoAboveVariable("C:\\Dll.dll", "Function", parameters);//sorry for this, but you should get the idea

    HINSTANCE dllhandle = LoadLibrary("C:\\Dll.dll");
    FARPROC functionaddr = GetProcAddress(dllhandle, "Function");

    typedef int (__stdcall *funcptr)(/*parameters are not pre-defined!*/);
    funcptr MyFunction = (funcptr)functionaddr;

    int ret = MyFunction(/*parameters are not pre-defined!*/);

    FreeLibrary(dllhandle);
    return 0;
}

Now obviously, the strings parameters[0 to 10] are filled with the parameters wich "Function" should be called with, for example if "Function" would be
int Function(int, char)
parameters will be

parameters[0] = "int"
parameters[1] = "char"

But the problem is, how do i call "Function" with the correct parameters?
And remember the parameters cannot be pre defined, the parameters will be known in runtime though, so... the program has to be able to call any function of any dll with the correct parameters.

From what ive read there seems to be no solution to this.

Thanks in advance!

(also im sorry if this should be posted in the C++ section, but i guess theres enough windows related stuff in it)

[kbw]

http://www.cplusplus.com/forum/general/8090/#msg37603

[Skillless]

I wrote:

And remember the parameters cannot be pre defined, the parameters will be known in runtime though, so... the program has to be able to call any function of any dll with the correct parameters.

kbw wrote:

http://www.cplusplus.com/forum/general/8090/#msg37603

Care to explain?

[kbw]

GetProcAddress returns the address of a function, but it cannot know what the type will be, so it just returns an arbitrary fixed type. But as you know the actual type, you need to cast it to the required type. Once you've cast this function pointer, the compiler can step in and enforce the parameters you pass to the function.

The example uses a typedef to define the functio

n type.
    typedef LONG (__stdcall *pCompress)(
                                LONG context,
                                const BYTE *in,
                                LONG insize,
                                BYTE *out,
                                LONG outsize,
                                LONG *inused,
                                LONG *outused,
                                LONG compression_level);

Then it uses the typedef to define the function.
pCompress Compress = (pCompress)GetProcAddress(hInst, "Compress");

Then it does the call will full type checking.
Compress(ctx, (BYTE*)in, insize, out, outsize, &inused, &outused, 9L);

[Skillless]

I wrote:

And remember the parameters cannot be pre defined, the parameters will be known in runtime though, so... the program has to be able to call any function of any dll with the correct parameters.

...

The program should be able to call any function of any dll without knowing the parameters the function before runtime

for example, the program reads from some text file that "FunctionA" has the parameters int, int, how does it call FunctionA now?

you say

typedef int (__stdcall *funca)(int, int);
funca FunctionA = funca(GetProcAddress(hInst, "FunctionA");

Sure, that works, but

I wrote:

the parameters cannot be pre defined, the parameters will be known in runtime though.

[Disch]

I don't think what you're trying to do is possible. The compiler needs to know the type in order to know which function you want to call.

IE: void Func(int) and void Func(double) are two different functions.... so in order to extract the right one from the DLL, you need to know the types of the parameters (as well as the return type).

The only way I can see to do this would be a massive if/else chain where you have every possible permutation of the parameter types and generate the appropriate function pointer type based on those types. Of course this is not advised and would be a nightmare to write and maintain.


Why on Earth do you need to do such a thing, anyway? If I were you I'd seriously redesign whatever it is you're trying to do. You're must be going about it in all the wrong way.

[Skillless]

The only way I can see to do this would be a massive if/else chain where you have every possible permutation of the parameter types and generate the appropriate function pointer type based on those types. Of course this is not advised and would be a nightmare to write and maintain.

Thats exactly what i had in mind and i was kindof looking for an alternative because it would be horror.

and

Why on Earth do you need to do such a thing, anyway? If I were you I'd seriously redesign whatever it is you're trying to do. You're must be going about it in all the wrong way.

Im making a sort of scripting language where the user would be able to use any function in any dll.
I read something about pushing the arguements on the stack with inline assembly but thats a bit too dangerous for me, and i dont know much(more like, nothing) about assembly.

[Disch]

That's an interesting problem.

Sorry to say I don't have any advise to give you on that one.

[kbw]

How could you be sure you were passing the right parameters?

[Skillless]

The user defines a header file; for example

MyDll.dll:
FunctionA int int
FunctionB char* int

And when the program reads this file, it knows that in MyDll.dll FunctionA takes an int and an int, and FunctionB takes a char pointer and an int

(And i indeed expect the user to never make a mistake ;P but thats not really the biggest issue)

[kbw]

So your scripting language is going to enforce the correct type and number of parameters are passed to the function with the correct calling convention just based on a prototype?

Are you going to pass syntax errors back to the user if the script passes the wrong parameter?

[Skillless]

Would there be a use for the user's header files if it wouldnt do it?

[kbw]

Was more a case of you being aware of what's involved. There's already a product that does all this, it's called Visual Basic.