On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent to attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven hard-linked GPS models, AP's etc it would be a problem, ;) I don't know in detail how plugin interfaces for other software (web browsers, gimp etc) have been designed, but I reckon the simplest way to do it (if one is only interested in keeping the text segment from gaining weight, not caring for independence) is linking the module/object in with the dlopen() when needed. That shouldn't take much code. (beware of symbol naming pitfalls, and although dlopen() is POSIX -- how portable it is to OSX or MSW, I have no idea.) I did a little experimenting with dynlinking classes in C++ years ago, trying to be pedantic with the OO, but after finally finding the code on my messy hd, I discovered I had left it in a state where it doesn't even build, and I don't remember anymore exactly how it was supposed to be. ;) (the files are dated feb-mar 1999) I expect there to be better examples floating about on the net. But what I did was, in short, rig two base classes: one for the core's view of the plugin. (the core cannot know the the plugin's real class name) And one for the plugin's view of the core. (to assure that the plugin is independent of internal changes in the core) Then the core would hook in the plugin with dlopen(), and call the plugin (construct it), sending over a handle to an object of the "Core" class. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
