Re: [boost] Any interest in static plugins?

Subject: Re: [boost] Any interest in static plugins?
From: Dave van Soest (dsoest_at_[hidden])
Date: 2009-11-30 14:00:54

Hi Christian,

> However, it is uninteresting to me. Relying on static initialiser ordering
> is a huge mistake which IMO cannot be fixed.

I may be wrong, but I think this can be fixed. First of all, the 
initialisation order of the plugins don't need any ordering, as they are 
retrievable by their id. Secondly, because the initialiser of the plugin 
factory uses a constant expression, the plugin factory is always 
initialised before main is entered. The initialiser of the factory 
manager is a non-const expression and is therefore initialised upon 
first usage, which is exactly when the first plugin factory tries to 
register itself.

So my point is: this static plugin code doesn't have to rely on static 
initialiser ordering.

> Factory models based on such approaches are doomed to failure. It is best to
> explicitly make a factory and then explicitly add runtime types dynamically
> (perhaps via a configuration file).
>
> This is not only more correct (the order or registration is repeatable), it
> preserves ideas of scope and removes requirements for globals.

I agree that the order of registration is not necessarily repeatable (at 
least not in different builds), but if the program relies on the 
ordering of plugin initialisation, then there might be something wrong 
with the program.

 >> static const static_plugin::Creator<SomeObject, ObjectBase> myPlugin;

As you can see in the code above, the 'myPlugin; is declared static 
(i.e. local to the source file), so there's nothing wrong with its scope.

I agree that global state should be prevented as much as possible, but a 
(static) plugin initialisation just is a global thing, and it should be.

Best regards,
Dave van Soest