From: Jason Hise (chaos_at_[hidden])
Date: 2005-01-10 22:16:04
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:
> if (object)
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk