Shallow vs. Deep Copy vs. Move Semantics: Memory Operations

1. Shallow Copy: The Default Danger

As we saw last time, if you don't provide a copy constructor, the C++ compiler generates one for you. This default constructor performs a shallow copy.

A shallow copy is a member-wise copy. For simple data types like int or double, this is fine. But for a pointer, it copies the address, not the data the pointer points to. This results in two objects believing they exclusively own the same resource.

Let's visualize the problem. Imagine our SimpleString class from the last lesson, where s1 holds "hello".

SimpleString s1("hello");
SimpleString s2 = s1; // Default copy constructor performs a shallow copy

Memory Layout (Shallow Copy):

• Stack: We have two objects, s1 and s2. The s2.data pointer is a copy of the s1.data pointer.
• Heap: There is only one block of memory containing "hello". Both s1.data and s2.data point to this same block.

The disaster occurs at the end of the scope. The destructor for s2 is called, which delete[]s the memory. Moments later, the destructor for s1 is called and tries to delete[] the exact same memory again. This is a double-free, leading to undefined behavior.

2. Deep Copy: The Correct (but Costly) Solution

To fix the shallow copy problem, we implement a custom copy constructor that performs a deep copy.

A deep copy creates a new, independent copy of the object, including any resources it manages. If the object contains a pointer to a dynamic resource, a deep copy allocates new memory for the copy and then copies the resource's content.

// Our custom copy constructor from the previous lesson
SimpleString(const SimpleString& other) {
    size = other.size;
    data = new char[size + 1];      // 1. Allocate NEW memory
    std::strcpy(data, other.data);  // 2. Copy the content
}

Memory Operations (Deep Copy):

1. A new object is created on the stack.
2. The copy constructor executes. It calls new to allocate a fresh block of memory on the heap, completely separate from the original object's heap memory.
3. The content from the original object's heap block is copied into the new heap block (e.g., using std::strcpy or a loop).

Now we have two distinct objects, each with its own independent resource on the heap. This is correct, but it can be expensive. For a large object like a vector with a million elements, you pay the price of a new memory allocation and copying a million elements. This is an O(n) operation, where n is the size of the data.

3. Move Semantics: The Efficient Transfer

Deep copies are essential for correctness, but as we noted, they can be slow. Consider this scenario:

SimpleString make_string() {
    return SimpleString("I am a temporary");
}

SimpleString my_string = make_string();

Here, make_string() returns a temporary SimpleString object. This temporary object will be used to initialize my_string and then will be immediately destroyed. Performing a full deep copy here is wasteful: we allocate new memory, copy the data, and then immediately free the original memory.

This is where move semantics come in. Instead of copying the resource, we transfer ownership. We "steal" the resource from the temporary object and leave it in an empty, but valid, state.

Memory Operations (Move):

1. A new object is created on the stack.
2. The move constructor executes. It copies the pointer (and size) from the source object to the new object.
3. It then sets the source object's pointer to nullptr. This is the crucial "stealing" step. It ensures the source object's destructor won't free the memory that now belongs to the new object.

This operation is incredibly fast. It involves only a few pointer and integer assignments, regardless of the size of the resource. This is an O(1) operation.

Under the Hood: A Concrete Analysis

Let's cement these ideas with a formal textual explanation and a concrete code example that prints memory addresses, leaving no doubt about what's happening.

Now for the definitive proof. The following resource provides a code example that prints the memory addresses of object members and their internal data pointers before and after copy and move operations. This is the "under the hood" view you've been looking for.

class Buffer {
    char* p_data;
    size_t size;
public:
    // ... Assume all 5 special members are defined ...
};

Buffer create_buffer(size_t n) {
    return Buffer(n); // Assume this constructor allocates 'n' bytes.
}

int main() {
    Buffer b1(1024); // Constructor
    Buffer b2 = b1;  // Line A
    Buffer b3 = create_buffer(2048); // Line B
}

Conclusion

You have now analyzed the three fundamental ways C++ handles object "duplication," right down to the memory operations. This knowledge is critical for diagnosing performance issues and ensuring program correctness.

Key Takeaways:

• Shallow Copy: Simply copies member values. For pointers, this copies the address, leading to two objects pointing to the same resource and an inevitable double-free error. It is almost always wrong for resource-managing classes.
• Deep Copy: Creates a new, independent resource for the copied object. This involves a potentially expensive heap allocation and data transfer (O(n)). It ensures correctness but can be slow.
• Move Semantics: Transfers ownership of a resource from a source object (usually a temporary) to a destination object. It is an extremely fast pointer-swap operation (O(1)) that avoids expensive allocations and copies. The moved-from object is left in a valid but empty/unspecified state.

In the last two lessons, we've seen how much manual work is required to correctly manage a simple pointer using the Rule of Five. This is error-prone and tedious. What if there was a way to get all the benefits of correct deep copies and efficient moves without writing any of these five special member functions yourself?

In our next lesson, we will introduce the RAII (Resource Acquisition Is Initialization) idiom. By using C++'s "smart pointer" classes, which are themselves perfect Rule-of-Five-compliant types, we can often achieve the "Rule of Zero," where the compiler-generated defaults do exactly what we want.