Boost logo

Boost :

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-01-10 18:34:33


>
> Is there any other functionality that should be added? Specifically,
> is it sufficient to enforce that singletons are created in a specific
> order before main and destroyed in the reverse order after main (using
> dependency instances), or should I provide some way to support
> alternate lifetimes (ex: create on first reference to instance)?
>
> Is there any interest in adding this library to Boost?

Well, one thing that would be interesting to support is the ability to
force the destruction and/or deconnection of all objects referenced
from a singleton...

For example, when programming with COM (ActiveX), we
might have a bunch of objects created by a singleton that
must be destroyed before we call CoFreeUnusedLibraries()
and/or CoUninitialize().

Also, with multiples DLLs, we typically need to ensure that
all references are destroyed before the system unload the
DLL. When there are complex depedencies, the system
might not knows which DLL to unload first and if some
of them have dynamic links to object in other DLL (via
the singleton), the application might crash when exiting.

This might also be interesting in some situations like
a singleton is associated with a document (or maybe
a window).

So 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).

Another reason that one might want to be able to
control when the destruction occurs is that it can
allows all code to be executed from a try/catch block
in main (so the application can report the error instead
of the OS).

Philippe


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk