From: Jeremy Pack (Jeremy.Pack_at_[hidden])
Date: 2006-10-07 13:08:14
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
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) ...
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
/*take care of initialization of my_factorable in constructor (public or
private constructor is fine)*/
And then in the code that creates it:
using namespace boost::extensions;
factory<extension> generic_factory =
/*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
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
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_at_[hidden]> wrote in message
> Agreed, important area to cover.
> For yade (my project) we have written a library for that, the code is
> 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
> 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk