A copy assignment operator of class is a non-template non-static member function with the name operator= that takes exactly one parameter of type T, T&, const T&, volatile T&, or constvolatile T&. For a type to be , it must have a public copy assignment operator.
|class_nameclass_name ( class_name )||(1)|
|class_nameclass_name ( const class_name )||(2)|
|class_nameclass_name ( const class_name ) = default;||(3)||(since C++11)|
|class_nameclass_name ( const class_name ) = delete;||(4)||(since C++11)|
- Typical declaration of a copy assignment operator when copy-and-swap idiom can be used.
- Typical declaration of a copy assignment operator when copy-and-swap idiom cannot be used (non-swappable type or degraded performance).
- Forcing a copy assignment operator to be generated by the compiler.
- Avoiding implicit copy assignment.
The copy assignment operator is called whenever selected by overload resolution, e.g. when an object appears on the left side of an assignment expression.
Implicitly-declared copy assignment operator
If no user-defined copy assignment operators are provided for a class type (struct, class, or union), the compiler will always declare one as an inline public member of the class. This implicitly-declared copy assignment operator has the form T& T::operator=(const T&) if all of the following is true:
- each direct base of has a copy assignment operator whose parameters are B or const B& or constvolatile B&;
- each non-static data member of of class type or array of class type has a copy assignment operator whose parameters are M or const M& or constvolatile M&.
Otherwise the implicitly-declared copy assignment operator is declared as T& T::operator=(T&). (Note that due to these rules, the implicitly-declared copy assignment operator cannot bind to a volatile lvalue argument.)
A class can have multiple copy assignment operators, e.g. both T& T::operator=(const T&) and T& T::operator=(T). If some user-defined copy assignment operators are present, the user may still force the generation of the implicitly declared copy assignment operator with the keyword .(since C++11)
The implicitly-declared (or defaulted on its first declaration) copy assignment operator has an exception specification as described in dynamic exception specification(until C++17)exception specification(since C++17)
Because the copy assignment operator is always declared for any class, the base class assignment operator is always hidden. If a using-declaration is used to bring in the assignment operator from the base class, and its argument type could be the same as the argument type of the implicit assignment operator of the derived class, the using-declaration is also hidden by the implicit declaration.
Deleted implicitly-declared copy assignment operator
A implicitly-declared copy assignment operator for class is defined as deleted if any of the following is true:
- has a user-declared move constructor;
- has a user-declared move assignment operator.
Otherwise, it is defined as defaulted.
A defaulted copy assignment operator for class is defined as deleted if any of the following is true:
- has a non-static data member of non-class type (or array thereof) that is const;
- has a non-static data member of a reference type;
- has a non-static data member or a direct or virtual base class that cannot be copy-assigned (overload resolution for the copy assignment fails, or selects a deleted or inaccessible function);
- is a union-like class, and has a variant member whose corresponding assignment operator is non-trivial.
Trivial copy assignment operator
The copy assignment operator for class is trivial if all of the following is true:
- it is not user-provided (meaning, it is implicitly-defined or defaulted) , , and if it is defaulted, its signature is the same as implicitly-defined(until C++14);
- has no virtual member functions;
- has no virtual base classes;
- the copy assignment operator selected for every direct base of is trivial;
- the copy assignment operator selected for every non-static class type (or array of class type) member of is trivial;
A trivial copy assignment operator makes a copy of the object representation as if by std::memmove. All data types compatible with the C language (POD types) are trivially copy-assignable.
Implicitly-defined copy assignment operator
If the implicitly-declared copy assignment operator is neither deleted nor trivial, it is defined (that is, a function body is generated and compiled) by the compiler if odr-used. For union types, the implicitly-defined copy assignment copies the object representation (as by std::memmove). For non-union class types (class and struct), the operator performs member-wise copy assignment of the object's bases and non-static members, in their initialization order, using built-in assignment for the scalars and copy assignment operator for class types.
The generation of the implicitly-defined copy assignment operator is deprecated(since C++11) if has a user-declared destructor or user-declared copy constructor.
If both copy and move assignment operators are provided, overload resolution selects the move assignment if the argument is an rvalue (either a prvalue such as a nameless temporary or an xvalue such as the result of std::move), and selects the copy assignment if the argument is an lvalue (named object or a function/operator returning lvalue reference). If only the copy assignment is provided, all argument categories select it (as long as it takes its argument by value or as reference to const, since rvalues can bind to const references), which makes copy assignment the fallback for move assignment, when move is unavailable.
It is unspecified whether virtual base class subobjects that are accessible through more than one path in the inheritance lattice, are assigned more than once by the implicitly-defined copy assignment operator (same applies to move assignment).
See assignment operator overloading for additional detail on the expected behavior of a user-defined copy-assignment operator.
Run this code
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
|DR||Applied to||Behavior as published||Correct behavior|
|CWG 2171||C++14||operator=(X&)=default was non-trivial||made trivial|
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.
To prevent copying, a C++ class needs to declare a copy constructor and an assignment 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.”)
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.
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 reference. Objects that are never passed by value can pragmatically disallow copying.