From: Dan Rosen (dan.rosen_at_[hidden])
Date: 2005-05-09 19:45:31
This is part of the rat-hole I was hoping to direct you away from in
the thread discussing your Singleton design in late March:
I am still of the opinion that the mechanism you're trying to develop
to protect against unwanted multiple instantiations of the singleton
object is orthogonal to the design of the singleton, and is clunky
My two cents.
On 5/9/05, Jason Hise <chaos_at_[hidden]> wrote:
> Tobias Schwinger wrote:
> > Jason Hise wrote:
> >> AFAIK, a pure virtual function is the only way to automatically make
> >> any derived classes un-instantiable.
> > Have you considered a protected (or even private if you want complete
> > uninstantiability) constructor?
> This will not automatically make derived classes uninstantiable. Client
> code should not be forced to provide a protected constructor if they
> wouldn't naturally need one... the uninstantiability, if that's a word,
> should be inherited automatically. A protected constructor would allow
> a public client default constructor to be generated automatically.
> Rob Stewart wrote:
> >Nope. The derived class dtor would be virtual
> >automatically. (12.4/7)
> In that case I'll apply the changes and get the new version online as
> soon as possible.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk