CODEWITHSUNDEEP
c++class-designcopying
John
John

Reputation: 16007

Guidance for when to explicitly enable/disable copying in C++ classes?

A colleague is cleaning up a couple of libraries. In doing so he's been reading API design for C++ and it talks about explicitly enabling or disabling copying in C++ classes. This is the same thing that Sutter and Alexandrescu say in their C++ Coding Standards.

He agrees that one should follow this advice, but what neither book seems to say are what are those guiding principles that tell when to enable or disable.

Any guidance one way or the other? Thanks!

Upvotes: 4

Views: 389

Answers (5)

Alexandre C.
Alexandre C.

Reputation: 56976

I sincerely believe that copy semantics should be provided automatically, or not at all.

However, badly written libraries may sometimes benefit from a manual copy constructor.

Note that the situation is very different in C++ (because copy semantics are usually required by the standard library !) than in C++0x, where my advice pretty much always applies.

Upvotes: 0

Nemanja Trifunovic
Nemanja Trifunovic

Reputation: 24561

Contrary to DeadMG, I believe most classes should be non-copyable.

Here is what Stroustrup wrote in his "The Design and Evolution of C++" book:

"I personally consider it unfortunate that copy operations are defined by default and I prohibit copying of objects of many of my classes"

Upvotes: 5

rve
rve

Reputation: 6055

I think you should try to write as little code as possible to have the class doing what it is supposed to do. If no one is trying to copy the class and it is not going to be copied in the near future then do not add stuff like a copy constructor or assignment operator. Just make the class non copyable.

When someday you actually want to copy the class, then add things like the copy constructor. But until then having the class non copyable means less code to test and maintain.

Upvotes: 0

James Kanze
James Kanze

Reputation: 153977

It depends on the role the classes play in the application. Unless the class represents a value, where identity isn't significant, you should ban copy and assignment. Similarly if the class is polymorphic. As a generally rule, if you're allocating objects of the class type dynamically, it shouldn't be copiable. And inversely, if the class is copiable, you shouldn't allocate instances of it dynamically. (But there are some exceptions, and it's not rare to allocate dynamically and avoid copying big objects, even when the semantics argue otherwise.)

If you're designing a low-level library, the choice is less clear. Something like std::vector can play many roles in an application; in most of them, copying wouldn't be appropriate, but banning copy would make it unusable in the few where it is appropriate.

Upvotes: 6

Puppy
Puppy

Reputation: 146968

Classes which are non-copyable should be the exception, not the rule. Your class should be non-copyable if and only if you cannot retain value semantics while copying- for example, named mutexes, unique-ownership pointers. Else, your class should be copyable. Many C++ libraries depend on copyability, especially pre-C++0x where they cannot be movable.

Upvotes: 5

Related Questions