Re: [boost] Is there any interest in static constructors?

Subject: Re: [boost] Is there any interest in static constructors?
From: Alexander Stoyan (alexander.stoyan_at_[hidden])
Date: 2013-02-04 12:51:05

Hello everybody,

Sorry for late response.

To Mateusz.
Thank you for a good point, I have updated my initial blogpost with with
clear statement of the goal. And I also corrected naming and put some extra
comments.

To Mathias.
>> What's the functional difference between putting it as a type list and
>> putting it as code?
Not sure that I understood your question correctly, but if you meant
differences between dependencies in the static_dependencies list and
dependencies
caused by calling initialization from main, then the difference is clear:
if we put dependencies B and C to static_dependencies list when declaring
class A, then only class A declaration becomes dependent on B and C. But if
we require a call to A::initialize, B::initialize and C::initialize from
main, then main becomes dependent on A, B and C. This way your startup code
will be dependent on everything like that, that's not right.

>> If you want it to be initialized before main, then use global variables  or
static members.
Ok, try to answer your question yourself:

struct A { static A& instance() { ... } }
struct B { static A& instance() { ... } }
struct C { static A& instance() { ... } }

...
static A& forceAConstr = A::instance();
static B& forceBConstr = A::instance();
static C& forceCConstr = A::instance();
...

int main() {
...
}

Can you guarantee the order of construction for A, B and C in this case
when standard explicitly states that the order of initialization is not
determined?

>> But then you have to make sure no threads exist prior to entering main.
>> Unlike for static variables in functions, global constructors are not
thread-safe.
Starting threads before main execution is a bad idea itself, so don't do it.

>> I have no idea what you're talking about. The compiler cannot remove
>> things if it changes observable behaviour, outside of a few situations
>> where copy constructors can be elided.
In my code you can find a declaration and initialization of  bool
static_constructible<T, Dependencies>::constructed. So, if this variable is
not referenced in the code it never get initialized. At least this is how
VS11 compiler works. So in order to refer this variable all data access
functions have to make a call to static_constructible<T,
Dependencies>::ensure_static_constructed.
This way if you call a data access function from main, which calls
ensure_static_constructed,
then static_constructible::constructed becomes referenced!

>> There is an "isinside" boolean.
That's only made for cases if a derived class from singleton does not
provide his own static constructor. If you remove B::static_construct() the
code will work fine anyway.

>> A given order can still be forced.
Unless it's through compile configuration, provide an example please.
Otherwise, having long lists of initialization orders for all supported
compilers is error prone. The code itself has to describe itself as much as
possible.

I appreciate your attention.
Thank you.
______________________________
With best regards,
        Alexander Stoyan