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(){}