There is a better way. I wasn't mocking you when I told you your design is flawed. Exponential growth in variations is a sign of bad design.
How do you you suggest I structure a function that is to be provided as a command in another programming language that lets someone send a function call with arguments.... but you don't know the types of the arguments that they are going to have to send in advance?
First ask yourself, even though they technically could send any type of argument, what types does your programming logic encompass? For example, a function that takes a base to a power, and is open to user input, could technically "take any form of input", but the only meaningful type of input is a numerical value. Furthermore, this could be constrained to floating point types.
Since you're struggling with the design, why don't you describe what your function logically does with the arguments?
In any case, the best way to deal with user input might be to accept everything as a giant string, or a series of string arguments. Then attempt to tokenize or parse into appropriate data types as appropriate.
Again, I want to steer you away from the "any input type possible" situation, and I ask that you make an effort to avoid it as well.
But if all fails, I would advise you to look at getopt or boost.program_options. They are used to work with program command line arguments, which means any type of input that must eventually be sorted into appropriate data types like strings, integers, and floating point.