From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-09 05:17:18
From: "Beman Dawes" <bdawes_at_[hidden]>
> At 06:50 PM 7/7/2001, David Abrahams wrote:
> >I have no attachment to this guideline and would be happy to strike it.
> >It's probably out-of-place in a boost document anyway.
> Seems sad to remove something that improves clarity of code and reduces
> coding errors just because some tools are broken.
A good argument.
I propose the following guideline:
"15.4. Try to provide reasonable copy and assignment semantics for a class.
If the class is explicitly designed to be noncopyable, either privately
derive the class from boost::noncopyable, or use
class X // noncopyable
X(X const &);
X & operator= (X const &);
Deriving a class from boost::noncopyable is less error prone than declaring
the private members explicitly, but comes at the cost of an extra
As for the "some tools are broken"... we don't determine which tools are
broken. The user does.
On a related note, I don't see anywhere in the coding guidelines a rule
about the implicitly generated class members; have I missed it? Something
"15.6. Keep in mind that the compiler will implicilty generate a copy
constructor, assignment operator and a destructor if you don't declare them
explicitly. If you rely on this behavior, document it using a comment inside
the class body:
// implicitly generated members are fine and useful
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk