Boost logo

Boost :

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

"miki jovanovic" <mik-_at_[hidden]> wrote:
original article:
> "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
      foo & operator=(const foo&);

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at