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