Copy constructor and copy assignment — Rule of Three: Worked examples

This page is the exhaustive drill for the Rule of Three. The parent note built why three members belong together. Here we hit every case a copy operation can throw at you — construction vs assignment, self-assignment, empty strings, chained assignment, the crash from the compiler-default version, exception safety when new[] fails, and the exam twist about counting how many times memory is allocated and freed.

Before we start, one word we'll lean on constantly:

The exact class we will step through

Every example below runs against this one file. Read it once now so that when an example says "Step 3 — free the old buffer", you can point at the literal line. This is a class (not an aggregate): its members are private, so the only way to touch them is through the constructors, destructor, and operator= shown here.

#include <cstring>   // strlen, strcpy
#include <cstddef>   // size_t
#include <utility>   // swap
 
class MyString {
    char*       data;   // owned resource: address of a heap buffer
    std::size_t len;    // length, NOT counting the '\0'
 
public:
    // (0) normal constructor
    MyString(const char* s = "") {
        len  = std::strlen(s);
        data = new char[len + 1];        // +1 for the '\0' terminator
        std::strcpy(data, s);
    }
 
    // (1) destructor — how the resource dies
    ~MyString() {
        delete[] data;                   // [] pairs with new[]
    }
 
    // (2) copy constructor — born as a deep copy
    MyString(const MyString& other) {
        len  = other.len;
        data = new char[len + 1];        // OWN, independent buffer
        std::strcpy(data, other.data);
    }
 
    // (3) copy assignment — overwrite an existing object
    MyString& operator=(const MyString& other) {
        if (this == &other) return *this;   // guard self-assignment
        char* tmp = new char[other.len + 1];// allocate FIRST (may throw)
        std::strcpy(tmp, other.data);
        delete[] data;                      // only now free the old buffer
        data = tmp;
        len  = other.len;
        return *this;                       // reference → chaining
    }
};

Now, three terms this page uses as headings — defined before we use them:

The scenario matrix

Copying an owning object has only a few moving parts, but they combine into distinct cases. Every worked example below is tagged with the cell it covers. The reader should never meet a situation we did not drill.

#	Case class	What's special	Example
C1	Birth-by-copy (copy constructor)	new object, no old buffer to free	Ex 1
C2	Rebirth-by-copy (copy assignment, distinct objects)	old buffer must be freed	Ex 2
C3	Self-assignment `a = a`	guard must fire, else copy-from-freed	Ex 3
C4	Indirect self-assignment `v[i] = v[j]`, `i==j`	aliasing hides the `a = a`	Ex 3b
C5	Degenerate input — empty string `""`	`len == 0`, still allocate 1 byte for `'\0'`	Ex 4
C6	Chained assignment `a = b = c`	why `operator=` returns a reference	Ex 5
C7	The broken default (no user copy ops)	shallow copy → double free crash	Ex 6
C8	`new[]` throws (exception safety)	object must survive an allocation failure	Ex 6b
C9	Copy-and-swap rewrite	one idiom covers C2, C3, C4 at once	Ex 7
C10	Exam twist — count allocations & frees	ledger must balance	Ex 8

The class's layout, restated compactly so the notation is unambiguous:

C1 — Birth-by-copy (the copy constructor)

Worked example Example 1 — a new object made from an old one

MyString a("cat");
MyString b = a;      // which special member runs?

Forecast: guess before reading — does this call the copy constructor or copy assignment? How many heap buffers exist afterward, and do they hold the same address or different addresses?

Step 1 — Identify the trigger. b did not exist on the line before. The = here is initialization, so it is member (2) the copy constructor MyString(const MyString& other), not operator=. Why this step? Because the whole file's correctness hinges on this distinction: a new object has no old buffer to free, so its code (member (2) above) must not call delete[].

Step 2 — Trace the constructor body. In member (2): len = other.len → 3. Then data = new char[3 + 1] grabs a fresh 4-byte block. Then strcpy copies "cat\0" into it. Why this step? Allocating fresh is what makes it a deep copy — b.data is a different address from a.data.

Step 3 — Count buffers. Two new[] calls happened total (one for a, one for b) → two independent buffers, each holding "cat". a.data != b.data.

Verify: two buffers ⇒ each destructor frees its own ⇒ two new[], two delete[], no address freed twice. Ledger balanced. ✅

Figure s01 (deep copy): alt-text — "Left: object a.data (magenta) and b.data (violet). Right: two separate orange buffers each holding cat\0." The magenta arrow is member (2) line data = new char[len+1] for a; the violet arrow is that same line running for b. Because each arrow ends in its own box, a.data != b.data. Trace them — they never meet.

Figure — Copy constructor and copy assignment — Rule of Three

C2 — Rebirth-by-copy (copy assignment, distinct objects)

Worked example Example 2 — an existing object overwritten

MyString a("cat");
MyString b("elephant");
b = a;               // b already lives — what must happen to its old buffer?

Forecast: b already holds an 8-char string. What happens to that buffer? If we skip a step here, do we crash or leak?

Step 1 — Trigger. b already exists, so this runs member (3) the copy assignment operator, not the constructor. Why this step? Because assignment carries an extra duty the constructor never has: disposing of what was already there.

Step 2 — Self-check. In member (3), if (this == &other) return *this; — here this is &b, &other is &a, and &a != &b, so we skip the early return. Why this step? The guard only matters when source and target are the same object; here they differ, so it does nothing yet (we drill the firing case in Ex 3).

Step 3 — Allocate the new buffer into tmp. tmp = new char[3 + 1], then strcpy(tmp, "cat"). Why this step? We allocate before touching b's old buffer so that a failed new[] cannot corrupt b (this is the exception-safe order — proven in Ex 6b).

Step 4 — Free the old buffer, then adopt tmp. delete[] data releases "elephant"'s 9-byte block; data = tmp; len = 3. Why this step? If we skipped the delete[], "elephant"'s block would be orphaned — a memory leak. See Dynamic memory new and delete.

Verify — the allocation ledger for this whole snippet: new[] for a (4B), new[] for b (9B), new[] for tmp (4B), delete[] b's old 9B. Then both destructors: delete[] a's 4B, delete[] b's 4B. Total: 3 allocations, 3 frees — balanced, no double free. ✅

Figure s02 (reassignment): alt-text — "b.data (violet) left; old grey elephant\0 buffer struck out top-right; fresh orange cat\0 buffer bottom-right." The magenta strike-through is Step 4's delete[] data. The violet arrow into the orange box is Step 4's data = tmp (whose contents came from Step 3's new char[len+1] + strcpy). Read top-to-bottom: free the old grey box, then repoint b at the new orange box.

C3 / C4 — Self-assignment (direct and hidden)

Worked example Example 3 — the object assigned to itself

MyString a("cat");
a = a;               // silly-looking, but must not crash

Forecast: if the guard if (this == &other) return *this; were missing, what exactly goes wrong?

Step 1 — With the guard (our actual code). In member (3), this == &other is true, so we return *this immediately — no allocation, no free, a untouched, still "cat". Why this step? This is what the guard buys: the self-case exits before doing anything risky.

Step 2 — Without the guard, using the old naïve order (delete[] first). Imagine member (3) had been the naïve delete[] data; data = new...; strcpy(data, other.data);. Then delete[] data frees "cat"; but other.data is that freed block, so strcpy copies from freed memory → garbage, undefined behaviour. Why this step? It shows the guard is not paranoia — omit it and the self-case really corrupts.

Verify: with the guard, a still equals "cat"; one new[] (construction) matched by one delete[] (destruction) — no extra free, no leak. ✅

Worked example Example 3b — self-assignment

in disguise (case C4)

MyString v[3] = {"x","y","z"};
int i = 1, j = 1;
v[i] = v[j];         // this is v[1] = v[1] !

Forecast: does the guard still save us when the aliasing hides behind indices?

Step 1 — Resolve the addresses. i == j == 1, so v[i] and v[j] are the same object: &v[i] == &v[j]. Why this step? The parent's warning — "who writes a = a?" — sneaks in through equal indices. The guard compares addresses, so it catches this too.

Step 2 — Guard fires. this == &other → early return, no damage.

Verify: v[1] still holds "y"; no buffer freed then read. One address-based guard covers C3 and C4. ✅

C5 — Degenerate input: the empty string

Worked example Example 4 — copying an empty string

MyString a("");      // len == 0
MyString b = a;      // copy an empty string

Forecast: len is 0. Do we allocate zero bytes? Is that safe?

Step 1 — Constructor arithmetic. In member (2): len = strlen("") = 0. Then data = new char[0 + 1] = new char[1] — a one-byte buffer. Why this step? Even the empty string needs room for its '\0'. Allocating len (not len+1) would give new char[0], and strcpy would then write the '\0' out of bounds — a buffer overflow. The +1 saves the degenerate case.

Step 2 — Copy. strcpy(b.data, "") writes a single '\0' into b's 1-byte buffer.

Verify: b.len == 0, b.data[0] == '\0', and b.data != a.data (still a deep copy). Two 1-byte allocations, two frees, balanced. The empty string behaves like any other length — because of the +1. ✅

Recall New angle: what if a caller passes

nullptr instead of ""? strlen(nullptr) is undefined — it is a stricter degenerate case than "". Our default parameter = "" only helps when the caller writes MyString x;; a caller who explicitly writes MyString x(nullptr) still crashes. ::: The empty-string case ("") is safe, but nullptr is a separate, harsher edge that our current constructor does not defend against — a real class would add if (!s) s = ""; as the first line.

C6 — Chained assignment

Worked example Example 5 — why

operator= returns a reference

MyString a("a"), b("b"), c("c");
a = b = c;           // three objects, one line

Forecast: in what order do the assignments happen, and what breaks if operator= returned void?

Step 1 — Associativity. = groups right to left, so this is a = (b = c). Why this step? We must resolve the inner b = c first and hand its result to the outer assignment.

Step 2 — Inner b = c. Member (3) overwrites b to "c" and return *this hands back a reference to b. Why this step? If member (3) returned void, there'd be nothing to feed the outer a = ... — the line wouldn't compile. Returning MyString& (not MyString by value) also avoids a pointless extra copy.

Step 3 — Outer a = b. The reference from Step 2 (which is b) is the right-hand side of the outer assignment, so a is overwritten to "c". Why this step? Chaining only works because Step 2 produced a usable value; had it returned void we'd have nothing to assign here.

Verify: after the line, a=="c", b=="c", c=="c". This is why the conventional signature is T& operator=(const T&) — see Operator overloading. ✅

C7 — The broken compiler default (the crash)

Worked example Example 6 — what happens if you write

none of the three

struct Bad {
    char* data;
    ~Bad() { delete[] data; }   // frees the buffer — but NO copy ops written
    // compiler therefore supplies SHALLOW copy ctor & operator=
};
 
Bad a;  a.data = new char[3];    // a owns a 3-byte buffer
{ Bad b = a; }                   // b copies a via the compiler's shallow ctor
// at '}':  b dies -> ~Bad() -> delete[] b.data
// later:   a dies -> ~Bad() -> delete[] a.data  (SAME address!)

~Bad() is defined (delete[] data); the crash is not a missing destructor but a shallow copy the compiler generated. Forecast: the compiler's automatic copy runs member-wise. What does that do to a pointer member, and where's the crash?

Step 1 — Member-wise copy. With no user copy ops, the compiler copies each member; for the pointer data it copies the address, not the buffer — a shallow copy. Now a.data == b.data. See Deep vs shallow copy.

Step 2 — First destruction. At }, b dies → delete[] b.data frees the block. a.data still holds that same, now-dangling address.

Step 3 — Second destruction. Later a dies → delete[] a.data frees the same address again → double free → crash.

Verify — the ledger is unbalanced: one new[], two delete[] on the same address. The fix is exactly to write the deep members (2) and (3) from the top of this page. See Destructors and RAII. ✅

Figure s03 (shallow crash): alt-text — "a.data (magenta) and b.data (violet) both point at a single orange hi\0 buffer via arrows labelled 'same address'." Both arrows land in one box — that is Step 1's member-wise pointer copy. The caption delete[] runs TWICE → CRASH is Steps 2 and 3. Compare with s01 (two boxes): here there is only one box with two owners.

C8 — When `new[]` throws (exception safety)

Worked example Example 6b — allocation fails mid-assignment

MyString b("elephant");
// ... system is out of memory ...
b = someHugeString;   // the new char[...] inside operator= THROWS

Forecast: with the naïve order (delete[] data; first, then new[]), what state is b left in when new[] throws? With our order (tmp first)?

Step 1 — Naïve order, walked in slow motion. delete[] data frees "elephant" → b.data is now dangling. Then new char[...] throws and the function unwinds. b.data is left pointing at freed memory. When b later destructs, delete[] b.data frees a dangling pointer → undefined behaviour. Why this step? It shows the naïve order is not merely ugly — a throw destroys the object.

Step 2 — Our order (member (3) above). tmp = new char[...] runs first. If it throws, we jump out before any delete[] or any write to b's fields. b still owns its intact "elephant" buffer — completely unchanged. Why this step? This is the strong exception guarantee: either the assignment fully succeeds, or the object is left exactly as it was. See Self-assignment and exception safety.

Verify: after a throw with our order, b still equals "elephant" and its single buffer is still live → one new[] (construction) will match one delete[] (destruction). No leak, no dangling pointer, ledger intact. ✅

C9 — Copy-and-swap rewrite (one idiom, three cases)

Worked example Example 7 — copy-and-swap on Example 2's scenario

MyString& operator=(MyString other) {   // by VALUE -> already a copy
    std::swap(data, other.data);
    std::swap(len,  other.len);
    return *this;
}               // 'other' dies here, taking the OLD guts with it

Apply it to: MyString b("elephant"); MyString a("cat"); b = a; Forecast: where does "elephant"'s buffer get freed in this version — and why is no explicit delete[] written?

Step 1 — The parameter is by value. operator=(MyString other) copies a into other using the copy constructor (member (2)). So other now owns a fresh "cat" buffer while b still owns "elephant". Why this step? All allocation is done before we touch b's state — so if new[] throws, b is untouched (this reuses the exception safety of C8, for free).

Step 2 — Swap. std::swap exchanges pointers: now b.data points at "cat", other.data at the old "elephant". Why this step? Swapping raw pointers is cheap and cannot throw — the risky work already happened in Step 1.

Step 3 — other destructs. At the closing }, other dies and its destructor delete[]s the "elephant" buffer it now holds. Why this step? This is where the old buffer is freed — automatically, no explicit delete[], no self-assignment guard needed (self-assignment just swaps b with a copy of itself, harmless).

Verify: b == "cat" afterward; "elephant" freed exactly once by other's destructor; self-assignment b = b copies then swaps-with-itself → safe. One idiom covers C2, C3, C4. ✅ Contrast with Move semantics and Rule of Five, which adds a move step for temporaries.

C10 — Exam twist: balance the ledger

Worked example Example 8 — count every allocation and free

// Correct Rule-of-Three MyString (from the top of this page).
MyString a("cat");        // (1)
MyString b = a;           // (2)
MyString c("dog");        // (3)
c = a;                    // (4)
a = a;                    // (5)
// scope ends: a, b, c all destruct

Forecast: how many new[] calls total? How many delete[]? Do they match?

Step 1 — Count allocations (new[]). (1) a ctor → 1. (2) b copy-ctor → 1. (3) c ctor → 1. (4) c = a: member (3) allocates tmp → +1. (5) a = a: guard fires (this == &other), so 0. Why this step? Every new[] is a debt; count the debts before checking they're paid. Total allocations = 4.

Step 2 — Count frees during execution. Only line (4) frees mid-run: c = a does delete[] on c's old "dog" buffer → 1 so far. Why this step? Buffers overwritten by assignment die before scope end; count them separately from destructor frees.

Step 3 — Count frees at scope end. Three live objects a, b, c remain; each destructor does one delete[] → 3. Why this step? Line (5) neither allocated nor freed, so a still holds exactly one live buffer — no double free.

Step 4 — Balance. Allocations = 4. Frees = 1 (during) + 3 (end) = 4. Why this step? A correct Rule-of-Three class always satisfies $# new[] = # delete[]$ , no address freed twice, none left unfreed.

Verify: $4 = 4$ ✅. If you counted 3 frees you forgot line (4)'s old-buffer release (a leak); 5 would wrongly charge line (5) with a free (a double free). ✅

Active recall

What decides copy-constructor vs copy-assignment for x = y?

Whether x is being created on that line (constructor) or already exists (assignment).

In Ex 2, why must operator= free b's old buffer?

b already owned the "elephant" buffer; skipping the free orphans it (memory leak).

Why must the self-assignment guard compare addresses, not values?

Two different objects can hold equal strings in different buffers; only this == &other detects true aliasing.

For MyString(""), why is new char[len+1] still safe?

len == 0 gives new char[1], one byte for the '\0', so strcpy stays in bounds.

Why does operator= return MyString&?

To support chaining a = b = c and to avoid an unnecessary by-value copy of the result.

In Ex 6, what makes the default copy crash?

Shallow pointer copy means two objects share one buffer, so delete[] runs twice on the same address.

In Ex 6b, why allocate into tmp before delete[] data?

If new[] throws, the object is left unchanged (strong exception guarantee) instead of holding a dangling pointer.

In copy-and-swap, where is the old buffer freed?

When the by-value parameter other (now holding the old guts) destructs at the end of the function.

In Ex 8, why does line 5 (a = a) add zero allocations and zero frees?

The self-assignment guard returns early before any delete[] or new[].

Recall Feynman: the ledger, in one sentence

Every time you say new[] you owe the universe one delete[] — no more, no less. A correct copy constructor and copy assignment just make sure that when objects copy each other, nobody double-pays, nobody skips the bill, and even if the shop runs out of memory mid-purchase, you still walk out owning exactly what you walked in with.