Boost logo

Boost :

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-01-10 22:42:02

> Philippe Mori wrote:
>> ...what is needed to cover such cases is the ability to set the object
>> in a "destroying" state.
>> A solution that could work in some situation would be something
>> similar to:
>> Singleton::Deconnect()
>> {
>> if (object)
>> {
>> object->Deconnect();
>> }
>> }
>> Well, the way to do the deconnection on the object hold by the
>> singleton would not be an hard-coded member but something that would
>> be settable by a policy class or some other template mean (for
>> example, type trait).
> I may be confused, but why couldn't (or shouldn't) this code be taken
> care of by the singleton's destructor in the derived class? It would
> seem that the derived singleton is the only thing that could possibly
> know about the specific things it needs to deallocate, and that a
> destructor would be a natural place to take care of it.
> -Jason

In some situations, we want to "shutdown" an application while
there are still references to the singleton (for exemple static variables)
and we want objects to be destroyed sooner that what will happen by

If it is difficult to guarantee that a singleton will not be used till
after a given point (where we want explicit destruction), it might
be safer to simply "Deconnect" the object. That is, delete is not
yet called but we do some cleanup (particulary removing references
to other object (or singleton)).

At my previous job we were using a lot of singleton where some
where in DLL and others would uses COM (ActiveX) object and
since some objects were having reference to others, if we were
not forcing a shutdown by calling a function on appropriate
singleton object, not every object was destroyed before we
call CoFreeUnusedLibrairies or before main was exited and DLL
where unloaded by the system.

And since with dynamically loaded DLL, the system does not
knows depedencies, singletons where destroyed in the order
that Windows decides to unload the DLL. The problem would
then occurs when while destroying a static object (typically a
singleton) that was referencing something in a DLL that the
system has unloaded, a crash would occurs.


Boost list run by bdawes at, gregod at, cpdaniel at, john at