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