Re: [boost] Is there any interest in static constructors?
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
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. 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:
But then you have to make sure no threads exist prior to entering main. Unlike for static variables in functions, global constructors are not
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,
There is an "isinside" boolean. That's only made for cases if a derived class from singleton does not
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
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? thread-safe. Starting threads before main execution is a bad idea itself, so don't do it. then static_constructible::constructed becomes referenced! provide his own static constructor. If you remove B::static_construct() the code will work fine anyway. possible. I appreciate your attention. Thank you. ______________________________ With best regards, Alexander Stoyan
On 04/02/13 18:51, Alexander Stoyan wrote:
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.
Not from main, but from A's constructor or initialize function.
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?
Not with the code as written, but you can rewrite it to enforce it.
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.
Of course. But if this is never referenced, then you cannot observe whether it has been initialized or not.
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.
Simple: make the dependency explicit.
participants (2)
-
Alexander Stoyan -
Mathias Gaunard