Quote:Original post by SteveDeFacto
There is no way I can provide a "standard" signature for all functions since all functions will have different inputs and outputs, the better option would be to use pure lua to bind the functions and classes but there are quite a few problems with that as well.
In C, you would have something like:
void (*arbitrary_C_plugin_function)(void*)
Where the void* parameter points to a context-dependent structure, or variable, or whatever else the particular function needs. That shifts the burden to the caller of the function, who needs to make sure they're passing in the right parameter. The code inside the function itself then knows how to properly cast the pointer to get the data it needs.
In C++, it looks more like:
void (*arbitrary_CPP_plugin_function)(const BaseData*)
or (if you have an instance)
void (SomeType::*arbitrary_CPP_plugin_function)(const BaseData*)
Where BaseData is a polymorphic type that can be downcast to the appropriate derived type based on the function. The only real difference is that you have a little more control over what the user passes in since it needs to be derived from BaseData, and you can leverage RTTI to make sure it's the correct type.
These solutions aren't ideal since things can still easily blow up at run-time if the calling code passes in the wrong thing, but that's how you handle the general case when you don't know the data types (or how much there will be) at compile-time. It isn't a bad idea to create wrapper functions around the plug-in functions that take the proper, compile-tile-checked parameters, so that you reduce the possible points of failure to a single location. However I'm not sure how much of this is possible in Lua.