Re: Avoid automatic copy constructor generation
On Oct 27, 11:03 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Ian Collins wrote:
Erik Wikstr=F6m wrote:
On 2008-10-27 19:29, Jeff Schwab wrote:
Juha Nieminen wrote:
Ian Collins wrote:
I can see the benefit of "= default", but what benefits does "==
delete"
offer over private constructors?
Declaring a constructor private is more a hack than a clean idiom.=
If
you accidentally call the copy constructor from the class itself, yo=
u
will not get a clean compiler error, but an obscure linker error, wh=
ich
is not really the best possible solution.
That's true if the private constructors are declared directly in the
non-copyable class. I wonder whether =delete offers anything over
EBO/inheritance-based utilities like boost::noncopyable.
Elegance and simplicity. A private copy-constructor is a hack but
boost::noncopyable is much worse, a complex solution to a simple
problem. Why should I have to inherit from some other class just to ma=
ke
my class non-copyable?
It may be a hack, but it's an idiomatic one that's been used
since the epoch of C++.
I don't consider it to be a hack, but an aid to
documentation. The reader can tell at a glance that the
class isn't copyable. It also saves typing!
Agreed. It's self-documenting, and doesn't require the reader
to be familiar with yet another language feature.
Yes and no. I used the techique back in the early 1990's. I
dropped it for awhile because readers weren't familiar with it.
The private copy constructor was the standard idiom, which they
immediately recognized, where as they didn't know what
UncopiableObject did; at the time, at least, it didn't occur to
them that a base class might have not direct interface, and they
expected something more. Thanks to things like std::iterator<>,
std::unary_function<>, etc., modern C++ programmers are far more
open about this, and when they see a class called
UncopiableObject, they don't expect anything more than that it
can't be copied. Some I've reverted to doing things the way I
did 25 years ago.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34