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