Hi Boosters! I was wondering if there is any interest for a static initialization library. The idea I currently have might look something like this: #include <iostream> #include <boost/init.hpp> using namespace boost; using namespace std; class myType { myType(int i) { cout<<"myType constructed with parameter "<<i<<endl; } }; void myFunc (int i) { cout<<"myFunc called with parameter "<<i<<endl; } extern init::variable<myType> myVar (42); init::function<void (), myVar> myInitFunc (myFunc, 35); init::variable<myType> myVar; int main () { init::init(); } The extern declaration of myVar simulates a global defined in a different translation unit - in this case, function is by the standard guaranteed to be initialized first, but if myVar is in a different TU, then the output is undefined. By passing myVar as a parameter to the function template, the library will ensure that the function is called after the variable (I was originally considering using a before<myVar> and after<myVar> syntax, but it would be too difficult to implement an algorithm that would be guaranteed to get the order right, whereas it's quite easy like this). The idea would be to allow an easy relationship for static initialization. I'm thinking that the variable class should act as a near-transparent wrapper by overloading all the operators. Since operator . is not overloadable, I would probably allow it to act through ->, unless the member is a pointer-like type (the exact definition of pointer-like could be controlled using template specializations). A member function would obviously be provided for accessing the object directly (such as to call a smart pointer's functions). Another idea is to have two separate classes (say, variable and wrapper), and only one has the wrapping behavior - the other has to have explicit access each time. The init function serves as the trigger for all the static initialization to occur (earlier actual initializations serve only to add the initializer to the queue) Functors would be provided to defer a function call (to get a constructor or function parameter) until the time that the initialization of the object takes place, rather than the initializer. If an exception is thrown, the initialization library will remember its state and then a subsequent call would take it off where it stopped. (adding new objects to the queue once initialization has begun would be allowable, allowing the initializer to be reused). Someone will no doubt at some point argue that I should wrap the functionality in a class to handle the initialization in order for different code to simultaneously take advantage of the facility, but I will dismiss that because it would fall prey to static initialization order and not work as intended. Perhaps later I will add a system that allows user code to store the current initialization list/state, but I don't think it would be worth the effort. One last question: Should I write this using C++09 variadic templates or the standard boost preprocessor techniques? I think that code written for variadic templates is more easily convertible to the preprocessor than vice versa, but I don't know. Thanks for your comments! Sean Hunt