Jeff Schwab said:
Passing a statically typed container by reference is "normal C++ style."
Circumventing the formal type system (e.g. with ellipses) is unusual.
A statically typed container is fine if the elements have the same
type, which is not the case here.
Circumventing the type system may be unusual in C++ programming
in general, but when interfacing with dynamically typed languages, it's
bread and butter. Many component systems work that way.
Right, so far so good. Shouldn't the host know, when it is compiled, how
many arguments each plugin function will expect? Plugins typically have
to conform to a fairly stringent API so that the host will know how to
invoke them.
But I'm going for a generic plugin mechanism. The APIs of individual
plugins are specified by a simple IDL which is interpreted by the host.
(Perhaps I should call it a "lightweight component mechanism".
It doesn't need to be too specific, but the quantity of arguments expected
by each function is pretty fundamental.
How about this: If the host provides a function template (rather than a
raw function) for registering the callbacks, then the static type of each
callback will be available to the host, and the number of arguments can be
gathered implicitly as part of the registration. Rather than just
registering a function pointer, the template instantiation (which knows
from the static type system how many arguments the callback expects) can
call an underlying registration function with both the callback function's
address and the number of arguments expected.
I'm having trouble understanding this.
The host and the plugin are compiled as separate projects. In which
of these would the callback registration function template be
instantiated?
If it is instantiated in the host, the host would have to be recompiled
when a new type of plugin is added, and this is precisely what I
want to avoid. The host is agnostic of the details of the plugin
interfaces until it gets the IDL at run time.
If its' instantiated in the plug - well, the template would either have
to construct a middleware layer between the plug and a generic
interface in the host, or somehow pass the type information to
the host in a format the host can interpret.
The "middleware layer" is above my template metaprogramming
skills - I think the PyBoost library does something like that but
I haven't found a description of the technique I understand.
The "type information passing" would not differ much from the
IDL based solution on the host side.
The only one of those I've used is Qt, and I'm not aware of it
using any kind of "dummy-argument technique."
If you check the QMetaObject Class Reference
http://doc.trolltech.com/4.4/qmetaobject.html
you'll find invocation methods that use dummy arguments.
I don't know for sure but it's my understanding that the
signal/slot mechanism uses these methods.
Qt [...] signal/slot mechanism [is] a slow, memory-hungry,
error-prone technique.
Agree, and I don't intend to copy it. I have much faster and safer
ways of doing the dynamic calls. I'm just having a problem with
dummy parameters and calling conventions.
That's an awfully low-level set of details to be worrying about
for something as high-level as a plugin architecture, which by
its nature should probably be defined as abstractly as possible
(so that a wide variety of client code will work with it).
"As abstractly as possible" may be fine when you combine things
at compile time, in an all C++ setting. But under the conditions
of having a host that is compiled to executable code without
knowledge of the plug API details, a low level interface is
required.
Btw what led me to design the plugin scheme was this case:
A collegue of mine implemented a glucose level simulation for
diabetes patients using Mathlab and some tools that produced
C code. I implemented a GUI for it using my interpreted PILS
language which comes with bindings to the juce GUI framework.
To make it work in a rush, I wrapped the glucose model C
code in a C++ class and fed it to the homebrew interface
generator I used to interface PILS to juce, and compiled it
into the PILS interpreter. But it doesn't really make sense
that my PILS language - which is rather general-purpose
- should come with a glucose simulation - and the app
shows some weird compiler- and optimization dependent
problems (oddly enough, with VC2008/WinXP, debug mode
works fine but release mode needed some optimizations turned
off for it to work, with GCC/Ubuntu, debug mode is flawed but
release mode works fine - this would be easier to diagnose if I
could compile and test the plugin separately.) ... so I need a
plugin system. I investigated UNO, Ice... but they are too
heavyweight, we want to be able to deploy on wrist watches
etc. so I need something light.
