Dan Rosen wrote:
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.
But this is not what I was suggesting. The client code at no point needs to even know that the virtual function exists, and it certainly shouldn't provide an implementation for it. The virtual function is declared in the singleton base class, and defined in the creator, both of which are provided by the library. The hierarchy is: singleton < test > (provided by library, pure virtual) | test (provided by client code, pure virtual) | creatable < test > (used internally by library and hidden from client code, concrete) This makes it so that client code can indeed do absolutely nothing, and still be guaranteed that rogue instances cannot be created. -Jason