Hello ppl I'm having a serious problem that I need to resolve both for Visual Studio in Windows and for MacOS. I have several static objects in various translation units (C++ source files) that happens to depend from each other for initialization and finalization. Now, when I changed the machine, their order has changed and the program is crashing. I know that this subject is delicate but there must be a way to solve this kind of problems. These object must be initialized and finalized outside the main (one of them is a memory tracking system, the other is a profiler and there are subsystems' initializations). Any idea?

The obvious answer is: "break this dependency". Static initialization and finalization is difficult to handle, and once you'll have handled it, your code will be more than difficult to understand. Not to mention that the static objects are ultimately global variables, so your code is prone to all the problems that global variables have.

If you can't, you're still lucky, because the C++ standard codifies the order of initialisation and finalization of static instances. Finalization is the easiest one: static objects are destroyed in the reverse order of the completion of their destruction. That means that if B has been created after A, then B will be destroyed before A. If B is constructed in A's constructor, the A will be detroyed before B (because the completion of A's construction takes place after the completion of B's construction).

Order of creation is a bit more difficult to get: you'd better read section 3.6, 3.7, 3.8 of the draft C++ standard very carefully if you want to get everything right (the draft standard text for this section is the same than the current standard text). It's a bit longer to explain, as it takes into account the different object types (POD, non-POD) and the different lifetime types (static, automatic and dynamic storage duration).

All in all, this is quite tough, and might need some simplification of your code to be easier to read/understand/modify later. As I hinted in my introduction, you're best bet is to change your design so that you don't have to rely on the order of creation/destruction of the object you're using.

Best regards,

Thanks for the fast answers. I think I have my solution. I have to do some refactoring to my code but the client code will be exactly the same, which is good.
The solution is based on Deks' solution, a very good solution. There will be one and just one static in my project that will instance all other system classes automaticaly.

Emmanuel Deloget:
Im using Visual C++ 2005 Express and I had a problem preciselly in a destructor. The Memory system was destroyed while there was still object. During a delete, the system tryed to access a map that was previously destroyed and crashed. I still did not read that document but that document is for ISO 2006. I think that it is the draft for the new C++ standard, the C++0x one, that may have new static rules on the future. At least for now, the VC++ express does not seem to being implementing that stuff.

Quote:Original post by Filami
Im using Visual C++ 2005 Express and I had a problem preciselly in a destructor. The Memory system was destroyed while there was still object. During a delete, the system tryed to access a map that was previously destroyed and crashed. I still did not read that document but that document is for ISO 2006. I think that it is the draft for the new C++ standard, the C++0x one, that may have new static rules on the future. At least for now, the VC++ express does not seem to being implementing that stuff.

The latest standard is from 2003. It's a correction of the 1998 standard. C++0x is not implemented yet, for the good reason that the wording is changing rapidely, and since it introduces a lot of new stuff (auto, ...), rules are likely to change a lot before it gets approved. Some stuff is already present in modern compilers, but most of the time it's only minor corrections (defects, such as defect 337, which changes the wording for type deduction failure cases in templates).

But there is nothing related to 2006.