Janek, I'll look through the links you sent me and give you a fuller answer.
From looking at the class_loader site, it looks very elegant - it's just missing one capability that is, for me, almost the most important.
Here's a bit more info about the library that I have: It is designed in such a way that the data needed for construction of one dynamic class may be provided by another dynamic class, and two dynamically created classes may communicate or share objects that they know about, but that were not known about by the interface in the .exe (i.e. these shared objects perhaps weren't even designed when the .exe was compiled). It's kind of difficult to explain, but I'll try to have an example soon. This is the primary thing that made me decide to write this library. I needed this capability. Because of this, you could create a plugin class that is not derived from some interface or other class, and still have it do useful things. It would have to be wrapped in a relatively generic class derived from my boost::extensions::extension class however, in order to load correctly. DISCLAIMER: Before I write code from the library, I want all of you macro haters to prepare to be angry with me. If someone can find a more elegant solution than my macros, I'll be very happy. I would love a template or inheritance based approach instead, but can't make one work. I'm sorry. On with the code. You could write basically: //#define BOOST_EXTENSIONS_CLASS_DECL(classname, superclass, description, requires, provides) ... BOOST_EXTENSIONS_CLASS_DECL(class factorable_wrapper,boost::extensions::extension, "A Generic Factorable Wrapper", "Requirements\nEach separated by returns or tab", "What this class provides\rAll requirements and provisions are strings")//This macro takes care of most everything for declaring //the class and making it loadable private: factorable my_factorable; /*take care of initialization of my_factorable in constructor (public or private constructor is fine)*/ }; And then in the code that creates it: int main { using namespace boost::extensions; loader my_loader; factory<extension> generic_factory = loader.get_factories<extension>(); } /*Note here that you'd have a problem that this generic_factory would now be able To pull in ANY class that is available from the dlls in the given directory (if no directory is specified, the initial_path (boost::filesystem) is used). That could be bad. I wouldn't do it this way. But it is possible.*/ In that constructor, you could pull the data that you need for construction from the repository. So yes, it would work, like that. As far as being able to pull in a boost::any, I could certainly get it to do that as well, I just don't see a good reason to (I think the above is more than sufficient). Once I put up my documentation on how the repository, requires, and provides concepts work, the above will be more clear. I really will get to that... I already have a functional prototype that compiles and works for sure with Mac OS X (GCC 4) and MSVC 8. It should, theoretically, have no problems on most Unix/Linux or Windows platforms. I have a couple of things I want to get taken care of before I publish it though (that's right: documentation). Jeremy Pack PS No worries. No singletons. In fact, you could have a couple dozen threads using the library, and it would work fine as long as they didn't share objects from the library between them (i.e. each thread needs its own loader object, own repository etc., otherwise some synchronization method would be required). "Janek Kozicki" <janek_listy@wp.pl> wrote in message news:<20061006235420.67bac1f2@absurd>...
Agreed, important area to cover.
For yade (my project) we have written a library for that, the code is here:
Not much documentation, just some comments in the code. It is basically a factory from Andrei Alexandrescu's book "Modern C++", just
a bit tweaked.
That code is short, so you can browse it for hints if you wish.
There is one HUGE mistake there: this library is using a singleton. Singletons hide complexity, don't do that people, I have learned my lesson. I'm currently looking forward to replace it with another more mature and better library, or rewrite yade's library applying 'parametrize from above' solution.
So far, the best candidate for replacement I have currently found is this one:
But you have just lighten up my hopes, because I will be more than happy to use a library for that, which is a part of boost.
I don't know _if_ and _when_ I'll go around to rewrite yade's plugin library, but I should be around to try and help you in writing one. Sadly it is time dependant, so I don't know hom much I will be able to
help.
PS: One question: is it technically possible, to make a plugin class _not_ derived from something (e.g. a class called factorable)? I was wondering about that, and couldn't answer.
-- Janek Kozicki | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost