Re: [boost] pure virtual singleton

From: Dan Rosen (dan.rosen_at_[hidden])
Date: 2005-03-25 11:48:10

Jason,

I think the part we're missing is the motivation behind this:

> Alright, allow me to clarify.  I want the singleton to behave as follows:
> [snip]
> I do not want to force client code to define protected constructors and
> destructors if they would not normally need them.

Why do you consider it so burdensome for client code to define
protected or private ctors/dtors that this has become a primary design
consideration? Of all the boilerplate code we have to write in our
day-to-day experience with C++, in my opinion, ctor/dtor declarations
aren't nearly the most odious. On top of that, I think that just about
any class that's worth making a singleton will contain some state, and
is therefore likely to need an explicitly declared ctor and/or dtor.
Also, for what it's worth, you'll notice if you look at Loki's
embodiment of the singleton pattern, that despite all its flexibility
and all the thought that went into it, clients of its SingletonHolder
class still must declare their ctor and dtor private.

To put it a different way: whether the client provides a trivial
implementation of a virtual function with an obfuscated name, or
whether the client implements private ctor and dtor, the client still
has to do *something* to enable proper usage. In the former case the
client is enabling correct construction and in the latter it's
disabling incorrect construction, but they're essentially equivalent
in that clients are forced to do some work. So my recommendation would
be: choose the route that's most idiomatic. We all know what it means
when ctors/dtors are declared private in an interface, whereas
implementing an arbitrarily-named and unused virtual function to
achieve essentially the same result is less clear and less familiar.

I hope I haven't missed some important reason why you need a singleton
that operates this way... Hope this helps,
dr