Subject: Re: [boost] Any interest in static plugins?
From: Dave van Soest (dsoest_at_[hidden])
Date: 2009-11-30 14:00:54
> 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
So my point is: this static plugin code doesn't have to rely on static
> 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.
Dave van Soest
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk