Re: [boost] Re: Suggestion to add class nonistantiable to utility.hpp

From: Ed Brey (brey_at_[hidden])
Date: 2000-05-25 13:17:09

From: "Miki Jovanovic" <miki_at_[hidden]>
> At first I thought that was the way to go. But then I thought of
some
> examples, how I would implement them, and soon I realised that
> classes are a better choice. With namespaces you have to chose
> between private members and inlining. Basically, most issues revolve
> around protection issues. You cannot make friends etc. All in all,
we
> probably have to enable both aproaches.

The detail namespace provides support for this to a degree.  For
example, all private/protected static functions could go in the detail
namespace.  While this approach works for simple needs, it isn't as
robust as having the full power of a class, which can differentiate
between protected and private and can grant friendship (rather than
have it be taken at will).

The detail namespace works well you have public classes or functions
that you don't want nested inside a class.  All in all, I would agree
that there are definately design patterns where each method is
superior.

> BTW, in response to other messages, this would probably solve the
> copy constructor problem:
>
> class noninstantiable : protected noncopyable {
>   private:
>     noninstantiable(){}
> }; // noninstantiable

Just like the copy constructors noncopyable, there should not be an
implementation for the default constructor in noninstantiable;
otherwise, a friend could instantiate it.  A situation where only
friends instantiate is unusual enough that it warrants setting up the
restriction constructors by hand, rather than relying on a convenience
base class such as noninstantiable to do it.

As far as the name goes, I would recommend nonconstructable.