On Apr 23, 2008, at 7:34 PM, Marvin Humphrey wrote:
To pull this off, we'll need to generate callback functions for each public method signature in the Lucy codebase.
I've now got auto-generation of callback functions working for all abstract methods, which allowed me to zap a bunch of tedious hand- rolled code. Now, declaring a function "abstract" in the header is all that's necessary; the code generator takes care of the rest.
It actually turned out to be one callback function for each method rather than for each signature because the variables need labels for calling back using hash-style params... but so far so good. I feel pretty confident that the overall approach will work. However, there's an implementation detail that's proving to be an annoyance.
Lucy needs to be able to receive a list of native method names from the host and decide which function pointers to replace in the vtable. However, C offers nothing in the way of introspection, so we have to build up our own metadata about each method: method name, location in the vtable, and function pointer for the auto-generated Lucy-method- implemented-as-native-callback.
If this were any dynamic language, the task would be trivial: we'd just build up the data using hashes, arrays, and strings. Since we're in C, though, we have to decide whether to declare this metadata using global vars, or load it dynamically at runtime.
Loading dynamically is a pain because we have to tear down at some point or leak memory -- but atexit() won't work, since the tear-down cue has to be host-language specific. The alternative is to declare globals. Unfortunately, C is very limiting in this regard, especially C89 -- because you can't build up complex data structures using anonymous structs. Hash tables are problematic even under C99, so with globals we have to go with arrays and then use bsearch() or something like that.
This isn't a truly hard problem. There are definitely many ways to make this introspection data available using C. But all the ways I've thought of so far are ugly.
Marvin Humphrey Rectangular Research http://www.rectangular.com/
