The C++ copy constructor is not just a language feature. It's the beating heart of value semantics, ownership logic, and the infamous Rule of 3/5/0. Understanding it in depth means understanding how C++ treats identity, lifetime, and low-level control.
This post walks from basics to internals, guiding you through practical examples, compiler strategy, and design combinations under the Rule of 3 or 5, or 0, if you've ever heard.
The basics of copy constructor
In C++, the copy constructor is a special constructor used to initialize a new object as a copy of an existing object. It has this canonical form:
MyClass(const MyClass& other);
It’s called when an object is:
- Initialized from another (e.g. MyClass b = a;)
- Passed by value
- Returned by value
- Stored in a container like std::vector (unless moved)
Unlike assignment, which replaces the value of an existing object, the copy constructor is about creating a new object.
Why do we need copy constructors?
Because C++ gives us value semantics, not just reference semantics like Java or Python.
In value semantics: each object is independent. A copy means a new instance with the same value, not the same reference.
This is powerful, but comes with a burden — when copying involves resource ownership, such as:
- raw pointers
- file descriptors
- sockets
- mutexes
- custom allocators
For these cases, the default copy constructor is broken. That’s because the default version just performs a member-wise shallow copy, which results in shared ownership and double-deletion if you're not careful.
When is the copy constructor used?
The copy constructor is invoked invisibly in many scenarios:
MyClass a = b; // direct copy
// or
foo(a); // passed by value
// or
return a; // (maybe) returned by value
// or
vec.push_back(a); // copied into container
Compiler optimizations like copy-elision and RVO (Return Value Optimization) may remove it — but that’s an optimization, not a guarantee (until C++17).
You can also manually call it:
MyClass b(a); // explicitly copy
How the compiler handles it?
Default copy constructor
If you don’t declare a copy constructor, the compiler generates one:
MyClass::MyClass(const MyClass& other)
: member1(other.member1),
member2(other.member2),
...
{}
Each member is copied using their own copy constructors.
If any member is not copyable, your class is implicitly non-copyable. You’ll get a compile-time error.
For example:
struct NonCopyable {
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
};
struct Wrapper {
NonCopyable resource; // This member is not copyable
};
int main() {
Wrapper a;
Wrapper b = a; // ❌ Compile-time error: Wrapper is implicitly non-copyable
}
/* Compile Error:
* use of deleted function ‘Wrapper::Wrapper(const Wrapper&)’
* Wrapper b = a; // Compile-time error: Wrapper is implicitly non-copyable
*/
Excecise: How to fixit this error?
Compiler internals
implicit vs default
Visibility
Use = default in headers to control public/protected/private behavior. Makes interfaces clear in public APIs.
Triviality
If the copy constructor is defaulted in the class definition, and all fields are trivial, then the whole type is trivial. Required for:
- memcpy()-safe objects
- ABI-compatible structs
- constexpr support
- Optimization (Inlining and RVO)
Compilers often inline trivial copy constructors. With optimization flags (-O2, -O3), the copy constructor is emitted as direct memory moves.
C++17 makes copy-elision mandatory in some cases:
#include <whatever>
T make()
{
return T(); // guaranteed elision in C++17, no copy constructor called at all
}
In C++14 and earlier, this could involve:
- Constructing a temporary T
- Copying/moving into the return value
In C++17, the standard mandates:
- The object is constructed directly into the caller’s storage.
- No copy or move constructor is ever called.
Rule of Three, Five, Zero
If your class manages a resource, you must define:
- Copy constructor
- Copy assignment operator
- Destructor
Otherwise, you get default ones, which often break.
In modern C++11+, we extend this to:
- Move constructor
- Move assignment
Plus these two cases, this is called the Rule of Five. These are generated only if none of the big five is user-declared. Mixing them causes suppression.
Rule of 0 (Modern STL idiom)
Prefer composition with RAII types (std::vector, std::string, unique_ptr) so that you don't need to define any of the big five.
Deep Dive: compiler suppression rules
That's why you should always define all five if you mix copies and moves. If you define any of the big five, the compiler suppresses the others:
When is copy constructor bad?
In modern C++, deep copying large resources is often undesirable. That's why:
- Use unique_ptr disables copy constructor
- Use shared_ptr implements reference counting
Best Practices for System-Level C++ Devs
- Use = default for clarity and triviality
- Use = delete to explicitly prevent behavior
- Don’t mix copies and moves unless you define all 5
- Favor std::unique_ptr, std::shared_ptr, std::vector for Rule of 0
- Watch for suppressed constructors in template code and header-only libs
- Benchmark cost of copy vs move when passing large structures or buffers
