[boost] Re: ABC similar to noncopyable

From: Mark Borgerding (mborgerding_at_[hidden])
Date: 2000-02-23 14:00:06

"miki jovanovic" <mik-_at_[hidden]> wrote: 
original article:http://www.egroups.com/group/boost/?start=2237
> "mark borgerding" <mborgerdin-_at_[hidden]> wrote: 
> 
> Well, most of you point were well taken, but maybe too strongly.

Sorry, if I came off too strongly.  I sometimes have a tendency to be a
bit overzealous.  In person, I am much more sensitive to feelings, but
still have been known to offend.  I hope I did not in this case.  I
think your idea is clever.  

> Following your thinking, noncopyable is also not a good idea, 

I think that the cost/benefit ratio is better for the noncopyable
class.  The notion of a class with a virtual destructor is more
difficult to succintly describe than the notion of a class that cannot
be copied.  The name of the class should be immediately descriptive of
its purpose.  I place a great deal of importance on a name.  The name
of a class is the first clue that a user has to its function.  I assume
that "abc" is just a placeholder, is there another name you had thought
of?  The name "abstract" jumps to mind, but it is not entirely
descriptive, since as soon as it is derived, the condition is met.
 I am assuming something like this would be the definition.
     class abstract {  virtual ~abstract() =0 {}  };

Besides, deriving from noncopyable saves two lines of definition that
(IMO) are more error prone, deriving from abc saves one that is fairly
goof proof.

I think typing 
   private:
      foo & operator=(const foo&);
      foo(foo&);

is more error prone than typing
   public:
      virtual ~foo(){}