On Thu, 24 Mar 2005 08:47:58 -0800 Dan Rosen <dan.rosen@gmail.com> wrote:
Hi Jason,
I haven't looked at singleton in any detail, so I can't answer your real question, but I wanted to offer a small suggestion, for what it's worth:
Rather than having a special function spelled "define_to_enable_creation," I wonder if it would be reasonable to declare singleton_base's destructor as pure virtual, forcing client code such as test_singleton to implement a destructor. If you wanted to enable the virtual behavior only for extra checking in debug mode, that'd be fine too:
class singleton_base { protected: #ifdef DEBUG virtual ~singleton_base() = 0; #endif // ... };
class test_singleton : public singleton_base { protected: ~test_singleton() { } // ... };
In debug mode, test_singleton's destructor is virtual as defined by its base class, and is necessary to implement. In release mode, test_singleton's destructor is not virtual unless you specify it to be. And implementing a trivial destructor like this is never harmful anyway.
Just a thought, but I might be totally missing something :) Cheers, dr
I do not understand what Jason is after either, but I thought a virtual destructor may offer some assistance, and it may, depending on what he is really trying to achieve. However, I thought I'd comment on your suggestion... A pure virtual destructor in singleton_base does not require the derived class to implement a destructor. Well, it does, but the compiler will automatically generate a destructor in the derived class. So you do not get the benefit or "forcing" the derived class to implement the destructor. Second, you still must provide an implementation of singletom_base::~singleton_base() because derived classes will call it in their destruction process. Remember pure virtual functions (including destructors) can have an implementation, and specifically for dtors, you must provide such implementation.