Hi i've just come across a really unpleasant problem - static destructors. what i want is to call an "exit" function after "everything". this means, after all calls to static destructors. i've tried the atexit C runtime library function, which adds a function pointer to a LIFO exit routine stack, but apparently MS VC++ (2005, havent tried other versions yet) uses the same 'atexit' exit routine stack to push a compiler generated function that calls static destructors - and this routine appears to be added somewhere during CRT initialization, assuring it definitely gets called after my custom exit routine. any ideas?

(the init_type is just an enumeration of initialisation priorities) Derived classes override the init() or uninit() method (or both), but contain no code (except variable initialisations) in their constructor. The actual code (like memory allocation/deallocation) has been moved to init()/uninit() CPP file:

At the beginning of the prg, i call the static i4_init() function, at the end, I call i4_uninit. This ensures all classes get initialized/deinitialized in a specific order. Since I use a lot more singletons than init_types, some of them still get called in a random order, but I can make sure that they don't depend on each other. As an example, I don't care in which order my INIT_TYPE_DLLS-type classes get called, but I care that they're called after the memory manager is initialized. Destruction happens in reverse order, of course.

It may seem that having a lot of static classes is bad design. In many cases, I completelly agree to this, but the advantage of the method I'm using is, that it adding an additional class can be done without modification of other code. Some of my classes will add themselves to other lists (besides the one used by the i4_init_class itself), like the list of game objects, or the list of user commands. So adding i.e. a new game object type is done by just declaring a static instance of such a class, which then knows how this new object is going to be constructed. With some macro tricks, this is only a single line of code, at the very location where the object itself is declared. I don't need to have a file where all my objects are listed, and which includes every object's .h file to be able to call the object's constructor.