Actually, even that won't work. Some people want to link our stuff in
statically. When they do this, there is no promise that our magic global
object won't destruct before theirs do, then their global object's try to
call some functionality that is already dead, and crazy hijinxs (sp?)
ensue.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Arnold, Curt" <[EMAIL PROTECTED]> on 01/25/2000 11:43:18 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces bug submission...
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;
