How would you design a C++ class so that objects of that class type can’t be copied? Why would you want objects that can’t be copied?
I have asked many people those two questions. For a long time those two questions were part of my standard repertoire of interview questions for candidates for positions requiring knowledge of C++. Most of the people I asked did not have ready answers. That was okay. The intent was to see how the candidate would approach solving the problem and how much knowledge of construction and assignment in C++ the candidate possessed.
How To
To prevent copying, a C++ class needs to declare a copy constructor and an assignment operator (operator=). At face value it’s counter-intuitive. To prevent copying, declare a copy constructor?
By default C++ allows copying. For any class that doesn’t declare its own, the C++ compiler will provide a default copy constructor and a default assignment operator. No good for a ‘no copy’ class.
Declare a copy constructor and an assignment operator so the compiler won’t provide the default versions but make both methods private and don’t provide implementations.
If an external non-friend function or class method calls the copy constructor or the assignment operator, compilation will fail because the methods are private. Friends and methods of the same class can call privates but compilation will still fail because the copy constructor and assignment operator are declared but not defined. (Intentionally declaring but not defining a method is sometimes termed “poisoning a method.”)
Example
class NoCopy
{
public:
…
private:
// copy ops are private to prevent copying
NoCopy(const NoCopy&); // no implementation
NoCopy& operator=(const NoCopy&); // no implementation
…
};
Why
Why would copying be disallowed? The motivations can be generalized as either logical or pragmatic.
Logical is when copying doesn’t make sense for the class type or model.
A class type that implements the Singleton design pattern is an example. A singleton should disallow copying by definition.
Another example might be a class type that wraps an external resource that has no copy semantics. For instance a class designer could decide that it is not meaningful for an object that wraps a thread to support copying.
A pragmatic motivation is when copy support doesn’t violate the class type’s logic but a decision is made to not allow copying anyway. This could be an exercise of the YAGNI principle. Or it could be based on knowledge that a copy operation for the given class type is very expensive and should be prohibited.
Class Design
A C++ class design is not complete if copying hasn’t been considered. Do the default copy constructor and assignment operator provide the correct copy behavior? Probably not if the class has any data members that are pointers. And if not, decide to either implement correct copying or disallow copying. Don’t leave a time bomb for the next programmer.
Unlike C++, Java requires an explicit decision to implement copying rather than providing a default that can be wrong. But objects in Java are all references and the ability to copy is actually rarely needed.
The Java experience can be emulated in C++ by preferring to pass objects by reference and const reference. Objects that are never passed by value can pragmatically disallow copying.
