Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Dave van Soest (dsoest_at_[hidden])
Date: 2009-12-03 15:38:41

Hi Jeremy,

> My team works on code that uses a lot of static initialization for global
> variables. Based on this difficult experience, I would highly recommend
> initializing the factories inside of functions called after main() has
> started, rather than in static initializers. The amount of code to make this
> work correctly across platforms is nontrivial. In fact, we require that a
> certain initialization function be called as soon as main() has started,
> just to clean up all of the messes left by doing static initialization of so
> many things. I believe that this original design was a mistake - but we have
> too much code to change it overnight.

I want the plugins to work without explicitly initializing them after 
main() has started. Because they are plugins, the rest of the program's 
code won't know anything about them. It only knows how to call them -- 
through the specified interface. If it can't work that way, it makes no 
sense to have this static plugin library.

I would be interested to learn what your and your team's experiences are 
in static initialization across platforms. You say it's nontrivial, can 
you please provide me some detail on this?

> I wouldn't call it "doomed to failure" - just difficult to get right, and
> probably not worth the effort to get it right.

Well, for the reasons I provide in my original post, I think it's worth 
it to get it right. But hey, you seem to be the first one around here 
not convinced that it's not feasible! That gives me some hope.

> I wrote some code for the sandbox a while ago that does this:
>
> http://boost-extension.redshoelace.com/docs/boost/extension/boost_extension/tutorials/tutorial02.html
>
> It works for both static and dynamic linking, and for shared libraries that
> are determined at run time (the shared libraries need to have been compiled
> with the same compiler options). It also allows arbitrary constructor
> signatures, inheritance across shared libraries, reflection and a few other
> features.

Your example uses a centralized place (the type-map) to store the 
information about the derived classes/plugins. That is what I'm aiming 
to avoid with my static plugin library.

Kind regards,
Dave van Soest