So I had a singleton and it had a good use: it was a event notification window that classes could register interest in messages (WM_*) from. I used a Meyer''s singleton to ensure it was constructed when necessary. And then the classes that registered for those were singletons, but I secretly knew they didn''t HAVE to be. So, I''m converting them to be static methods. I figured out I could make a static instantation of the class like so:

static TimerManager singleton 

in the cpp file. However I still have problems with the destructor:

TimerManager::~TimerManager()
{
	EventNotifier::Instance().Unregister(this, WM_TIMER);
} 

Since order of destruction is undefined it is possible the EventNotifier instance would be gone before the TimerManager''s. Is there any way to get around this? I looked at the GD article but am not quite sure how it applies to singletons that need defined order of destruction.

Even worse, the TimerManager''s destructor could cause a new singleton to be created, since none exists after EventNotifier''s destructor is called.

Since the client managers depend on EventNotifier, the destructor should notify each client that it is going away. The client could unregister at that point. That smells like "delete this" and it opens up the possibility of recursion and other potentially nasty things, but it still seems like the right thing to do.

Then when the managers'' destructors are called, they are already unregistered, and they can skip that step.

Look for an old C++ User''s Journal article that described how to ensure the creation order of singletons as well as an article that described a method of ensuring the order of destruction of singletons. They both appeared in the same issue... I just can''t find any reference to the issue at the moment... when I get a chance - I''ll dig through my box of CUJ''s and find that issue if you need me to. *GRIN*

Dave "Dak Lozar" Loeser

Amusing.

EventNotifier creates a window in the constructor. CreateWindow fires a message to the window before WinMain is even executed and it ends with an access violation.

Man it was NICE abusing singletons, at least it worked...

http://www.cs.wustl.edu/~schmidt/PDF/ObjMan.pdf
Talks about making an 'uber-singleton' to manage all the other singletons and providing a defined construct/destruct order.

Edit: today isn't gettinga ny better.

[edited by - antareus on June 3, 2003 10:18:08 PM]

Okay I know how to handle this.

If you have layered singleton relationships then typically one of them is more important than the others and must be destroyed last. In a child singleton:

static AsyncSocketManager* singleton = new AsyncSocketManager; 

Register that singleton with the more important one. In the important one''s destructor, delete the child singleton.

Make the top-level singleton a Meyers singleton. Since there is only one singleton controlling them all (yeah it slate), order of destruction is now defined: child singletons before parent. There are no resource leaks, either.

just make global pointers, and create/destroy them in the right order in the main function. there is no syntactical difference.

if you have such troubles with your singletons, you''re asking for too much. just create the things in your main function in the order you want and all your troubles are gone.

"take a look around" - limp bizkit
www.google.com