You could make and maintain a paired list of function names and their pointers (along with type info about the parameters and such), and when a script function is invoked, seek that list for the function pointer given the name.

This is essentially how "professional" vtables work, albeit usually they use numeric indices in the function list for speed instead of string compares in a symbol-based approach.

Note that this is not automatical - you'd still have to "export" the scriptable functions yourself - but when you define a function in the script, you can append it to the symbol list (of course, you need to compile the function first somehow).

Variable type info can be as simple as an array of enumeration values. The enumeration would consist of type flags, for example VT_INT, VT_FLOAT, VT_ZTSTRING, VT_POINTER and so on, with which each parameter in the vtable would be flagged. The enumeration could have an extra value, VT_VOID, to denote the parameter list end (or void, if used as the only parameter or return value of a function).

You might want to extend the type info structure a bit from that, to store metadata and such, as .net does. However, that may not be necessary, depending on the desired robustness of the system.

A good script-side approach would be to use only variants in the script (a'la JScript, VBScript, php...), and determine their types and counts at the script compile time.

EDIT: After you have the parameter types (and parameter count derived from the position of the VT_VOID flag), it is only a matter of copying the parameters to your virtual stack - that is, the script callback function - and executing the correct function from the vtable saved previously.

EDIT2: I just realized your problem :)
The script callback's parameters would include the pointer to the parameter list of the currently executed function. That enables the script engine to call the callback generically with all functions, as the callback enumerates the parameter lists in any case.

[Edited by - Nik02 on August 28, 2004 2:51:45 AM]

You could, of course, replace the simple array of enumeration values to something more complex, like a name/value map or even a small database. It's only more work, but you do get additional robustness in return.

The simple array as a parameter list I talked about was just an example. You do need a some kind symbol export/import system anyway, and that is the easiest (if not by far the most complete) way of implementing one.

C++ itself doesn't call random functions, actually; the linking procedure binds symbols very precisely, conceptually similar to the system we've discussed here, but a bit more low-level. You do need to explicitly export from c++ also, if you want to use the functions from outside of the module - and the linker will construct the export table with the symbolic info just like you're about to do in your project, only with your own linker logic.

I just wanted to add, that while you cannot call "random" functions (that is, not exported from the c++ core system), you can of course write your own functions in the script and then call them from c++ - I see this as much more powerful ability [smile]

And while you're at it, you could add LoadLibrary* and FindProcAddress wrappers to your script's symbol table, and you'd have dll loading capabilities in your script. Do notice that this is potentially a huge security risk if you actually publish the code in your app, and let the users write scripts.