C++ Copy Constructor — Fixing Double-Free Shallow Copy Bugs

Every serious C++ program eventually needs to duplicate objects — passing one to a function, returning one from a method, or storing one in a container. At that moment, C++ must answer a critical question: what does 'make a copy' actually mean for this specific class? For a simple integer that answer is obvious, but the moment your class owns a raw pointer, opens a file handle, or manages a network socket, a naive byte-for-byte duplicate can silently corrupt your program. That's the problem the copy constructor was designed to solve.

The copy constructor is a special member function that C++ calls whenever an object is initialised from another object of the same type. It lets you define exactly what 'copy' means for your class — whether that's a shallow mirror image, a fully independent deep clone, or something in between. Without a thoughtful copy constructor, two seemingly separate objects can end up sharing the same underlying memory, leading to double-free crashes, dangling pointers, and data corruption that only shows up at the worst possible moment.

By the end of this article you'll understand why the compiler-generated copy constructor is sometimes a ticking time bomb, how to write a correct deep-copying version, when to delete it entirely, and how to talk confidently about it in a technical interview. We'll build a realistic DocumentBuffer class step by step so every concept has immediate, tangible context.

What the Compiler Generates — and Why That's Sometimes Dangerous

If you don't write a copy constructor, the compiler generates one for you. This default version performs a member-wise copy: it copies each data member from the source object into the new object one by one. For value types like int, double, or std::string, that works perfectly because those types already know how to copy themselves correctly.

The danger arrives with raw pointers. If your class holds a char or int pointing to heap memory, a member-wise copy duplicates the pointer value — the memory address — not the data it points to. Both the original object and the new copy now point at the exact same block of heap memory. Neither object knows the other exists.

When the first one is destroyed, its destructor frees that memory. When the second one is later destroyed, its destructor tries to free memory that's already gone. That's undefined behaviour, and on most platforms it's an immediate crash.

This is called a shallow copy, and understanding it deeply is the single most important prerequisite for writing correct C++ classes that manage resources.

#include <iostream>
#include <cstring>

namespace io::thecodeforge::examples {

// A naive buffer class that does NOT define a copy constructor.
// The compiler will generate a shallow copy — watch what happens.
class NaiveBuffer {
public:
    char* data;   
    int   size;

    NaiveBuffer(const char* text) {
        size = static_cast<int>(std::strlen(text)) + 1;
        data = new char[size];           
        std::strcpy(data, text);         
        std::cout << "[Construct] Allocated buffer at address "
                  << static_cast<void*>(data) << "\n";
    }

    ~NaiveBuffer() {
        std::cout << "[Destroy]   Freeing buffer at address "
                  << static_cast<void*>(data) << "\n";
        delete[] data;                   
    }
};

}

int main() {
    using namespace io::thecodeforge::examples;
    NaiveBuffer original("Hello, CodeForge");

    // The compiler's shallow copy constructor runs here.
    NaiveBuffer copyOfBuffer = original;  

    std::cout << "Original address:  " << static_cast<void*>(original.data) << "\n";
    std::cout << "Copy address:      " << static_cast<void*>(copyOfBuffer.data) << "\n";

    // When main() exits, the double-free crash occurs here.
    return 0;
}

Writing a Deep Copy Constructor That Actually Works

A deep copy constructor solves the shared-pointer problem by allocating brand-new memory for the copy and then copying the data across — not just the address. The result is two completely independent objects that happen to hold identical data at that moment in time.

The signature of a copy constructor is always the same pattern: ClassName(const ClassName& source). The parameter is a const reference to the same type. It must be a reference — if it were passed by value, C++ would need to copy it, which would call the copy constructor again, causing infinite recursion. The const is there because copying shouldn't modify the source.

Let's fix our NaiveBuffer by renaming it DocumentBuffer and adding a proper copy constructor, copy assignment operator, and destructor — the full Rule of Three in action.

#include <iostream>
#include <cstring>
#include <algorithm>

namespace io::thecodeforge::core {

class DocumentBuffer {
public:
    char* content;   
    int   capacity;  

    explicit DocumentBuffer(const char* text) {
        capacity = static_cast<int>(std::strlen(text)) + 1;
        content  = new char[capacity];
        std::strcpy(content, text);
        std::cout << "[Constructor] Created at " << (void*)content << "\n";
    }

    // --- The Deep Copy Constructor ---
    DocumentBuffer(const DocumentBuffer& source) {
        capacity = source.capacity;
        content  = new char[capacity];          // Allocate FRESH memory
        std::strcpy(content, source.content);   // Copy actual DATA
        std::cout << "[Copy Constructor] Cloned to " << (void*)content << "\n";
    }

    // --- The Deep Copy Assignment Operator ---
    DocumentBuffer& operator=(const DocumentBuffer& source) {
        if (this == &source) return *this;      // Self-assignment guard

        delete[] content;                       // Cleanup existing resource
        capacity = source.capacity;
        content  = new char[capacity];
        std::strcpy(content, source.content);
        std::cout << "[Copy Assignment] Re-assigned at " << (void*)content << "\n";
        return *this;
    }

    ~DocumentBuffer() {
        std::cout << "[Destructor] Freeing " << (void*)content << "\n";
        delete[] content;  
    }
};

}

int main() {
    using namespace io::thecodeforge::core;
    DocumentBuffer draft("TheCodeForge");
    DocumentBuffer backup = draft; // Copy Constructor
    return 0;
}

When to Delete the Copy Constructor — and the Move Constructor Alternative

Sometimes copying an object makes no logical sense. A database connection, a file handle, or a mutex represent unique real-world resources that can't meaningfully be duplicated. If you copy a database connection object, should both copies now own the same connection? The safest answer is to make copying impossible by deleting the copy constructor.

C++11 introduced the move constructor as a complementary tool. Where a copy says 'make me an identical twin', a move says 'transfer ownership to me — the original gives up its resource'. Moves are typically $O(1)$ operations because they just swap pointers, whereas deep copies are $O(N)$.

#include <iostream>
#include <string>
#include <utility>

namespace io::thecodeforge::db {

class DatabaseConnection {
private:
    std::string* conn_string;

public:
    explicit DatabaseConnection(const std::string& str) {
        conn_string = new std::string(str);
        std::cout << "[DB] Connection opened.\n";
    }

    // DISABLE COPYING
    DatabaseConnection(const DatabaseConnection&) = delete;
    DatabaseConnection& operator=(const DatabaseConnection&) = delete;

    // ENABLE MOVING (Ownership Transfer)
    DatabaseConnection(DatabaseConnection&& other) noexcept : conn_string(other.conn_string) {
        other.conn_string = nullptr; // Leave donor in valid but empty state
        std::cout << "[DB] Connection moved.\n";
    }

    ~DatabaseConnection() {
        if (conn_string) {
            delete conn_string;
            std::cout << "[DB] Connection closed.\n";
        }
    }
};

}

int main() {
    using namespace io::thecodeforge::db;
    DatabaseConnection conn("sql://prod:5432");
    // DatabaseConnection copy = conn; // This would cause COMPILE ERROR
    DatabaseConnection moved_conn = std::move(conn); // This works!
    return 0;
}

When the Copy Constructor Gets Called — and the Traps You'll Hit

The copy constructor isn't just for explicit =. It's triggered in three common scenarios that often surprise junior engineers:

1. Pass by value: void func(MyClass obj) — every call copies the object.
2. Return by value: MyClass create() { MyClass tmp; return tmp; } — the return value is copied unless copy elision kicks in.
3. Container insertion: std::vector vec; vec.push_back(obj); — stores a copy.

But here's where the traps lie: if you pass a temporary (rvalue) to a function that expects a parameter by value, the compiler may use the move constructor instead if available. If your class has only a copy constructor and not a move constructor, the copy constructor will be called even for temporaries — which is a performance hit. Also, brace initialisation (MyClass obj = {arg}) might call the copy constructor if the constructor is explicit.

Understanding when copying happens is critical for performance-critical code. Every unnecessary copy in a hot path adds O(n) time and memory pressure.

#include <iostream>
#include <vector>

namespace io::thecodeforge::examples {

class Tracker {
public:
    int id;
    Tracker(int i) : id(i) { std::cout << "Construct " << id << "\n"; }
    Tracker(const Tracker& s) : id(s.id) { std::cout << "Copy " << id << "\n"; }
    Tracker(Tracker&& s) noexcept : id(s.id) { s.id = -1; std::cout << "Move " << id << "\n"; }
    ~Tracker() { std::cout << "Destroy " << id << "\n"; }
};

Tracker create() {
    Tracker local(1);
    return local; // Moves or elides
}

void consume(Tracker t) { /* pass by value */ }
}

int main() {
    using namespace io::thecodeforge::examples;
    Tracker a(2);
    Tracker b = a;       // Copy
    Tracker c = create(); // Move or elision
    consume( create() );  // Move into parameter
    std::vector<Tracker> v;
    v.push_back(a);       // Copy into vector
    return 0;
}

Copy Elision and Return Value Optimization (RVO) — When the Copy Doesn't Happen

The C++ standard allows compilers to elide (skip) a copy or move constructor call under specific circumstances, even if the constructor has side effects. This is called copy elision. The most common form is Return Value Optimization (RVO): when a function returns a local variable, the compiler can construct it directly into the caller's variable, skipping the copy or move.

Since C++17, guaranteed copy elision is mandatory for certain cases: when a prvalue (pure rvalue) is used to initialise an object directly. That means MyClass obj = MyClass(42); constructs obj in place without calling the copy or move constructor — period.

Understanding elision is vital because you cannot rely on side effects in copy/move constructors for correctness. The compiler may or may not call them. RVO also affects performance: if you disable it (e.g., by returning std::move(local) instead of local), you may inhibit elision and force a move that's actually slower.

#include <iostream>

namespace io::thecodeforge::examples {

class Tracked {
public:
    Tracked() { std::cout << "default\n"; }
    Tracked(const Tracked&) { std::cout << "copy\n"; }
    Tracked(Tracked&&) noexcept { std::cout << "move\n"; }
    ~Tracked() { std::cout << "~destruct\n"; }
};

Tracked make() {
    Tracked local;
    return local; // RVO: may elide copy/move
}

}

int main() {
    using namespace io::thecodeforge::examples;
    Tracked obj = make(); // C++17: guaranteed elision
    Tracked x = Tracked(); // prvalue init: no copy
    return 0;
}

The Rule of Five: Expanding for Move Semantics

With C++11, the Rule of Three became the Rule of Five. If your class manages a resource, you should now consider defining:

• Destructor
• Copy constructor
• Copy assignment operator
• Move constructor
• Move assignment operator

If you define a destructor, copy constructor, or copy assignment operator, the compiler will deprecate the default move operations (they are implicitly defined, but you should explicitly define them for correctness and performance). Similarly, if you define move operations, the copy operations are implicitly deleted.

In practice, if you're following the Rule of Five, use the copy-and-swap idiom for the copy assignment operator. It provides strong exception safety and reduces code duplication. The move constructor and assignment operator can simply swap pointers.

#include <iostream>
#include <cstring>
#include <algorithm>

namespace io::thecodeforge::core {

class Resource {
    char* data_;
    size_t size_;
public:
    explicit Resource(const char* s) {
        size_ = std::strlen(s) + 1;
        data_ = new char[size_];
        std::strcpy(data_, s);
    }
    ~Resource() { delete[] data_; }

    // Copy
    Resource(const Resource& other) 
        : size_(other.size_), data_(new char[other.size_]) {
        std::strcpy(data_, other.data_);
    }
    Resource& operator=(Resource other) { // copy-and-swap
        swap(*this, other);
        return *this;
    }

    // Move
    Resource(Resource&& other) noexcept 
        : Resource() { // default constructor
        swap(*this, other);
    }
    Resource& operator=(Resource&& other) noexcept {
        if (this != &other) {
            delete[] data_;
            data_ = other.data_;
            size_ = other.size_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }

    friend void swap(Resource& a, Resource& b) noexcept {
        using std::swap;
        swap(a.data_, b.data_);
        swap(a.size_, b.size_);
    }
};

}

int main() {
    using namespace io::thecodeforge::core;
    Resource r1("Hello");
    Resource r2 = r1;           // copy
    Resource r3 = std::move(r1); // move
    r2 = Resource("World");     // move assignment
    return 0;
}

Default Copy Constructor — Why Your Pointer Just Became a Landmine

When you don't write a copy constructor, the compiler generates one for you. It does what's called a memberwise copy — it copies each member exactly as-is, bit by bit (for trivial types) or member-by-member (for classes). That sounds harmless until you have a pointer, a file handle, or a dynamically allocated buffer.

The moment both objects point to the same heap memory, you've lost. Delete one, and the other holds a dangling pointer. Write to one, and you silently corrupt the other. Junior devs call this a 'shared state bug'. Senior devs call it Tuesday afternoon.

For classes that only contain primitive types or standard containers like std::vector, the default copy constructor works fine. But anything with raw ownership of a resource? You're one innocent Object copy = original away from a double-free in production. The compiler doesn't warn you because it assumes you know what you're doing. Don't prove it wrong.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
#include <cstring>

class Buffer {
    char* data;
    size_t size;
public:
    Buffer(const char* str) : size(strlen(str) + 1) {
        data = new char[size];
        memcpy(data, str, size);
    }
    ~Buffer() { delete[] data; }
    void print() const { std::cout << data << '\n'; }
};

int main() {
    Buffer original("production");
    Buffer copy(original);  // Default copy constructor
    
    original.print();
    copy.print();
    return 0;  // BOOM: double free
}

Copy Constructor vs Assignment Operator — They're Not the Same Operation, Stop Treating Them Like They Are

Both copy an object's state into another. But one creates life, the other mutates it. The copy constructor initializes a new object from an existing one. The copy assignment operator replaces the contents of an already-living object. That difference matters when you manage resources.

In a copy constructor, the target object doesn't exist yet — its members are uninitialized. So you allocate fresh. In assignment, the target already holds resources that need proper cleanup before you overwrite them. Forget to release the old buffer in operator= and you've got a leak. Use assignment logic in your copy constructor and you'll crash on uninitialized pointers.

Here's the line that trips up most devs: MyClass a = b; — that's a copy constructor, not assignment. The = is syntactic sugar for initialization, not a call to operator=. If you've written a custom assignment operator but not a copy constructor, you just copied with cleanup code aimed at a non-existent target.

Write both. Or delete both. But never assume one can stand in for the other. They're siblings, not twins.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

class Config {
    int* id;
public:
    Config(int value) : id(new int(value)) {}
    
    // Copy constructor: initialize
    Config(const Config& other) : id(new int(*other.id)) {
        std::cout << "Copy ctor\n";
    }
    
    // Copy assignment: replace
    Config& operator=(const Config& other) {
        if (this != &other) {
            *id = *other.id;  // reuse existing memory
            std::cout << "Copy assign\n";
        }
        return *this;
    }
    
    ~Config() { delete id; }
};

int main() {
    Config a(42);
    Config b = a;  // Copy ctor
    Config c(0);
    c = a;         // Copy assign
}

Copy Elision and RVO in C++17

Copy elision is a compiler optimization that eliminates unnecessary copying or moving of objects. In C++17, guaranteed copy elision was introduced for certain cases, making it a language requirement rather than just an optimization. This means that when a prvalue (pure rvalue) is used to initialize an object of the same type, the copy or move constructor is not required to be accessible or even defined. This is particularly important for factory functions and return value optimization (RVO).

Consider a function that returns an object by value:

```cpp struct MyType { MyType() { std::cout << "Default constructor "; } MyType(const MyType&) { std::cout << "Copy constructor "; } MyType(MyType&&) { std::cout << "Move constructor "; } };

MyType createObject() { return MyType(); // prvalue }

int main() { MyType obj = createObject(); // guaranteed copy elision in C++17 } ```

In C++17, the above code will only call the default constructor once. The copy and move constructors are not invoked because the prvalue MyType() is used to directly initialize obj. Before C++17, compilers might have performed this optimization, but it was not guaranteed, and the copy/move constructor had to be accessible.

Another form of copy elision is named return value optimization (NRVO), where a named local variable is returned. NRVO is not guaranteed but is widely implemented. For example:

``cpp MyType createObject() { MyType local; return local; // NRVO may elide the copy/move } ``

In C++17, if the compiler applies NRVO, the copy/move constructor is not required to be accessible, but if it doesn't, the move constructor (or copy if move is not available) must be accessible.

Understanding copy elision is crucial for writing efficient C++ code. It allows returning large objects from functions without performance penalties, and it enables the use of types that are non-copyable and non-movable in certain contexts, as long as they are returned by value from a factory function.

However, be aware that copy elision can affect the behavior of code that relies on side effects in copy/move constructors (e.g., logging). Since the constructors may not be called, such side effects may not occur as expected.

#include <iostream>

struct MyType {
    MyType() { std::cout << "Default constructor\n"; }
    MyType(const MyType&) { std::cout << "Copy constructor\n"; }
    MyType(MyType&&) { std::cout << "Move constructor\n"; }
};

MyType createObject() {
    return MyType(); // prvalue
}

int main() {
    std::cout << "Creating object:\n";
    MyType obj = createObject();
    std::cout << "Done\n";
    return 0;
}

Rule of Five: Copy, Move, Destructor, Copy/Move Assignment

The Rule of Five states that if a class defines a custom destructor, copy constructor, or copy assignment operator, it likely needs all five special member functions: destructor, copy constructor, copy assignment operator, move constructor, and move assignment operator. This rule evolved from the Rule of Three (destructor, copy constructor, copy assignment) to include move semantics introduced in C++11.

Why is this important? If a class manages a resource (e.g., dynamic memory, file handle, network connection), the default compiler-generated functions may do shallow copies, leading to double-free errors or resource leaks. By explicitly defining all five, you ensure proper resource management.

Consider a simple Buffer class that owns a dynamically allocated array:

``cpp class Buffer { int data; size_t size; public: Buffer(size_t s) : size(s), data(new int[s]) {} ~Buffer() { delete[] data; } // Copy constructor (deep copy) Buffer(const Buffer& other) : size(other.size), data(new int[other.size]) { std::copy(other.data, other.data + size, data); } // Copy assignment operator Buffer& operator=(const Buffer& other) { if (this != &other) { delete[] data; size = other.size; data = new int[size]; std::copy(other.data, other.data + size, data); } return this; } // Move constructor Buffer(Buffer&& other) noexcept : data(other.data), size(other.size) { other.data = nullptr; other.size = 0; } // Move assignment operator Buffer& operator=(Buffer&& other) noexcept { if (this != &other) { delete[] data; data = other.data; size = other.size; other.data = nullptr; other.size = 0; } return *this; } }; ``

Notice the move operations are marked noexcept, which is important for optimizations like using std::vector's reallocation (which prefers noexcept move constructors).

If you omit move operations, the compiler will use copy operations instead when moving, which can be inefficient. Conversely, if you define move operations, the compiler will not generate copy operations automatically (unless you explicitly default them).

In modern C++, it's often recommended to follow the Rule of Zero: design classes that do not manage resources directly (use RAII wrappers like std::vector, std::string, std::unique_ptr). Then the compiler-generated special members work correctly. But if you must manage resources, follow the Rule of Five.

#include <algorithm>
#include <iostream>

class Buffer {
    int* data;
    size_t size;
public:
    Buffer(size_t s) : size(s), data(new int[s]) {}
    ~Buffer() { delete[] data; }
    Buffer(const Buffer& other) : size(other.size), data(new int[other.size]) {
        std::copy(other.data, other.data + size, data);
    }
    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            delete[] data;
            size = other.size;
            data = new int[size];
            std::copy(other.data, other.data + size, data);
        }
        return *this;
    }
    Buffer(Buffer&& other) noexcept : data(other.data), size(other.size) {
        other.data = nullptr;
        other.size = 0;
    }
    Buffer& operator=(Buffer&& other) noexcept {
        if (this != &other) {
            delete[] data;
            data = other.data;
            size = other.size;
            other.data = nullptr;
            other.size = 0;
        }
        return *this;
    }
};

int main() {
    Buffer b1(10);
    Buffer b2 = b1; // copy
    Buffer b3 = std::move(b1); // move
    b2 = b3; // copy assignment
    b2 = std::move(b3); // move assignment
    return 0;
}

std::exchange for Efficient Move Assignment

When implementing move assignment operators, a common pattern is to transfer ownership of resources from the source object to the destination. Using std::exchange can make this operation more efficient and exception-safe. std::exchange replaces the value of an object with a new value and returns the old value. This is particularly useful for setting the source object's pointer to null after moving.

Consider a move assignment operator for a class that manages a raw pointer:

``cpp class Resource { int data; public: Resource& operator=(Resource&& other) noexcept { if (this != &other) { delete data; // release current resource data = std::exchange(other.data, nullptr); // steal resource and set other to null } return this; } }; ``

Without std::exchange, you might write:

``cpp data = other.data; other.data = nullptr; ``

But std::exchange does both in one step, which is clearer and can prevent mistakes if the order of operations matters. Additionally, std::exchange is constexpr and noexcept in C++20, making it safe for use in noexcept functions.

Another advantage is that std::exchange works well with smart pointers. For example, moving a std::unique_ptr:

``cpp class Container { std::unique_ptr ptr; public: Container& operator=(Container&& other) noexcept { ptr = std::exchange(other.ptr, nullptr); // or just std::move(other.ptr) return *this; } }; ``

In this case, std::move is simpler, but std::exchange can be useful when you want to explicitly set the source to a known state.

std::exchange is also handy in copy-and-swap idiom, though that idiom is less common with move semantics. Overall, using std::exchange in move assignment operators improves readability and safety, especially when dealing with multiple resources or complex state.

However, be cautious: std::exchange is not a silver bullet. For simple cases, direct assignment and nullification are fine. But for consistency and clarity, especially in generic code, std::exchange is a valuable tool.

#include <utility>
#include <iostream>

class Resource {
    int* data;
public:
    Resource(int* d = nullptr) : data(d) {}
    ~Resource() { delete data; }
    Resource(Resource&& other) noexcept : data(std::exchange(other.data, nullptr)) {}
    Resource& operator=(Resource&& other) noexcept {
        if (this != &other) {
            delete data;
            data = std::exchange(other.data, nullptr);
        }
        return *this;
    }
    void print() const { std::cout << "Data: " << (data ? *data : 0) << '\n'; }
};

int main() {
    Resource r1(new int(42));
    Resource r2;
    r2 = std::move(r1);
    r2.print();
    r1.print(); // r1 is now empty
    return 0;
}