Dean Roddey wrote:
For use, its mainly the inderminant order or creation and destruction.
There is no good way, that is portable, to make sure that things get
created and cleaned up in the right order. This is particularly sticky in
the case of the objects that were in question in this topic, e.g. the
transcoder, message loader, ect... because of the fact that if anything
goes wrong on the way down, there could be an attempt to use these things
after they have been cleaned up.
------------
Thanks for the clarification. I definitely agree that the order can hose
you when you have dependencies on other classes having been initialized.
On the dangling resources issues, if you can determine a safe order of
destruction, you could enforce it in the destructor of one global object
that handles unload cleanup.
In some cpp file (using a more appropriate name)
class XercesSwampRat
{
public:
//
// assume all global pointers are already being initialized to 0
//
XercesSwampRat() {}
//
// called on DLL unload, releases global resources
// in a controlled order
//
~XercesSwampRat()
{
//
// some explicit order determined by interdependencies
delete gMsgMutex;
gMsgMutex = 0;
delete defXCode;
defXCode = 0;
...
}
} swampRat;
