Function pointer question

Question

ok, let it be known that I am generally a c++ programmer, so some parts of c I am a bit unfamiliar with.  this generally includes generic (un-typesafe) casting and things of that nature (as c++ is supposed to be typesafe).
So here's my question.  I'm trying to strap a c interface on top of something.  The internal code allows for "generic" slots to be attached to a signal.... errm let me demonstrate with pseudo-code:
void func1(int);
bool func2(int,long,char*);
add_slot("signal1",func1);
add_slot("signal2",func2);
now... in the c++ portion, I can take advantage of templates in order to make it generic.  But when interfacing to C, I can't do that.  I was thinking I should just do something like:
typedef void* slot_func;
add_slot(char*,slot_func);
and just enforce the call at runtime.  it's what I have to do with the c++ portion, as due to the generic-ness (?) it can only be enforced at runtime...
can any c programmer point me in a better direction (if there is one)? I checked out some other code-bases, and things like irssi defines the "slot_func" as void f(void*,void*,void*,void*,void*); which just seems messy to me... *shrug*
thanks ina dvance for comments...

Answer 1

i3839 wrote:
If you only want to make a generic layer which provides a way to connect and combine multiple plugins, then it's much easier, I think. All it needs to do is let plugins find eachother and provide a communication channel.
Then it more or less boils down to two things, depending on the grand scheme: Plugins can generate events, and handle events.
yup, that's exactly what I was thinking...
i3839 wrote:All specific event details aren't important for the generic layer, that is something the plugins choose and implement. In this case each event is handled as a unique type: The plugin which handles it should know how to handle the data, if any. Think (void* data, int length), or just void* data, if you don't have variable length data but only strings and pointers to structures and stuff.
yeah, again dead-on to what I was thinking.  that would work, but I find it a bit sloppy... well... maybe it would *appear* cleaner doing:
typedef void* callback_data;
typedef bool (*callback)(callback_data);
i3839 wrote:The trickier part is what to do with multiple plugins handling the same event.
the internals would be c++ signals and slots (I may actually use a different implementation than boost or libsigc++) in which case, they are basically linked lists of slots assigned to a signal... the reason I defined the callback as a bool is because it's not hard to make a signal interruptable... and it's not hard to simply add a slot or add a slot at a certain position in the list (think priority!)... that way the following would happen:
signalX.emit(data);
//slot[0] called, returns true
//slot[1] called, returns true
//slot[2] called, returns false - emit ends
//slot[3] never called
i3839 wrote:Of course this way plugins may have too much freedom and the whole may be too dynamic, so you could restrict how plugins communicate with eachother.
yes, agreed... which is part of the reason I was straying from the raw "void*" stream of data...
I was trying to make it so specific parameters can be defined by each signal... and documented by each plugin itself:
pluginA defines a signal with the signature: void foo(int,void*), named "signalA"
pluginB tells the core to connect "void bar(int,void*)" to "signalA" (by name)
pluginC tells the core to connect "bool baz(struct stat)" to "signalA"
at runtime, the connection made by pluginB will succeed and work perfectly.  however, the connection made by pluginC will not work (it's undetectable at compile time... sigh), yet this is found as soon as signalA is emitted (called) - an error is reported and that slot is disconnected from the signal
this is, of course, all implemented in C++ and uses some RTTI (yeah yeah, I know... there's only space overhead for classes with virtual members.. which I don't use often)