philburk
Using CreateGlueToC without a shell
I'm trying to understand why using CreateGlueToC requires a shell (as it's behind a #if (!defined(PF_NO_INIT)) && (!defined(PF_NO_SHELL))). This seems like a fully embedded usage couldn't also have exposed C/C++ functions. Is there a reason this is the case?
Good question.
I think the CreateGlueToC() function is only needed when compiling the initial custom C code. Once it is compiled then you should be able to make a TURNKEY dictionary, or a static dictionary, that can still execute the custom code.
The second compilation of the pForth kernel should be able to use PF_NO_SHELL and then run the turnkey dictionary.
OK. I had not realized that the C functions were described by the dictionary.
My original idea was to use pforth embedded in a program where extra C functions are not actually known at compile time. A series of plugins would be dlopen'ed/LoadLibrary'ed, and then a list of functions would be enumerated and added at program start. Does this mean that situation require the dictionary to be recreated whenever the set of plugins changed?
A series of plugins would be dlopen'ed/LoadLibrary'ed,
You could use the custom C functions to call dlopen, dlsym, etc. You could also have a custom C function that pulled the parameters off the stack and then called the raw function pointers. You could do all this without dictionary headers.
and then a list of functions would be enumerated and added at program start.
You could define an AUTO.INIT function that called the plugin loader.