Dynamic Allocation of Arrays of Objects with Raw Pointers: Rule of Three and Deep Copy Issues

Dynamic memory management in C++ is a complex yet critical topic. When classes contain raw pointer members, directly using dynamically allocated arrays can lead to difficult-to-debug issues. This article analyzes the root causes and provides solutions through a typical scenario.

Problem Scenario Analysis

Consider the following class definition containing a dynamically allocated integer array:

class A
{
    int* myArray;
public:
    A() : myArray(nullptr) {}
    A(int size) : myArray(new int[size]) {}
    ~A() { delete[] myArray; }
};

When attempting to create a dynamically allocated array of A objects:

A* arrayOfAs = new A[5];
for (int i = 0; i < 5; ++i)
{
    arrayOfAs[i] = A(3);
}

This code causes undefined behavior. The core issue lies in the assignment operation arrayOfAs[i] = A(3). The compiler-generated default assignment operator for class A performs a shallow copy, copying only the pointer value rather than the pointed-to data. The temporary object A(3) is destroyed at the end of each loop iteration, calling the destructor to free memory, leaving objects in the array with dangling pointers.

Rule of Three and Deep Copy Necessity

For classes containing raw pointers, the Rule of Three (extended to Rule of Five in C++11) must be followed: if a class needs a destructor, it usually also needs a copy constructor and copy assignment operator. The compiler-generated defaults are unsuitable for managing exclusive resources.

Proper implementation requires deep copy:

class A
{
    size_t mSize;
    int* mArray;
public:
    A(size_t s = 0) : mSize(s), mArray(new int[mSize]) {}
    
    ~A() { delete[] mArray; }
    
    // Deep copy constructor
    A(const A& other) : mSize(other.mSize), mArray(new int[mSize])
    {
        std::copy(other.mArray, other.mArray + mSize, mArray);
    }
    
    // Copy assignment operator (using copy-and-swap idiom)
    A& operator=(A other) // Pass by value, automatically creates copy
    {
        swap(*this, other);
        return *this;
    }
    
    friend void swap(A& first, A& second) noexcept
    {
        using std::swap;
        swap(first.mSize, second.mSize);
        swap(first.mArray, second.mArray);
    }
};

The copy-and-swap idiom handles exception safety and self-assignment automatically through pass-by-value parameters. Swap operations should be marked noexcept to ensure strong exception safety guarantees.

Modern C++ Improvements: Rule of Five and Move Semantics

C++11 introduced move semantics, extending to the Rule of Five: adding move constructor and move assignment operator. This allows transfer of resource ownership rather than copying:

class A
{
    // ... member variables as above
public:
    // Move constructor
    A(A&& other) noexcept : mSize(0), mArray(nullptr)
    {
        swap(*this, other);
    }
    
    // Move assignment operator
    A& operator=(A&& other) noexcept
    {
        swap(*this, other);
        return *this;
    }
    
    // Destructor, copy constructor, and copy assignment as above
};

Move operations leave the source object in a valid but unspecified state, typically implemented via swapping. Marking them noexcept is crucial for standard container optimizations.

Simplified Solution Using Standard Containers

For most applications, using std::vector avoids the complexities of manual memory management:

class A
{
    std::vector<int> mArray;
public:
    A() = default;
    A(size_t size) : mArray(size) {}
    // No need to explicitly define destructor, copy/move operations
};

std::vector automatically manages memory, provides exception safety guarantees, and supports dynamic resizing. For arrays of objects, std::vector<A> is equally safe and efficient.

Practical Recommendations and Summary

When dynamically allocating arrays of objects, standard containers should be prioritized. If raw pointers must be used, implement the full Rule of Three/Five. Deep copy ensures each object owns an independent resource copy, while move semantics optimizes handling of temporary objects. Always test self-assignment and exception safety, using tools like Valgrind to detect memory errors.

Understanding these concepts not only solves the immediate problem but forms the foundation of writing robust C++ code. As C++ standards evolve, smart pointers and container libraries offer safer alternatives, but mastering underlying principles remains essential.