Managing Dynamically Allocated Arrays in Classes

A Vector class that stores its elements in a dynamically allocated array has a hidden problem: copying the object is not the same as copying a few numbers. The object holds a pointer to an array that lives on the heap, and the default way C++ copies an object only duplicates the pointer. Two objects would then refer to the same array, and a change through one would appear in the other. This article works from two member functions of a Vector class: a copy constructor, which builds a new Vector from an existing one, and a copy assignment operator, which overwrites an existing Vector with the contents of another.

The approach here is to trace the code before explaining it. Follow the state of two Vector objects one line at a time, and at each step ask which object is being read and which is being written. Then come back to the functions and check your expectation against what the program actually does.

Suppose a Vector x already holds three values and a Vector y holds two different values. The program then executes x = y. Before the first line of the function runs, x owns an array of three values and its size field sz is 3. Inside the function, the parameter a refers to the same object as y, so a.sz is 2 and a.elem refers to y's array. Each step below changes only the state of x, because the copy assignment operator writes to the object it is called on and only reads from its argument.

The copy constructor performs two jobs. First, it allocates new memory for the copy. Second, it copies the elements from the original object. The member initializer list carries out the allocation: elem{new double[a.sz]} requests an array with as many doubles as the original holds, and sz{a.sz} records the same size. The body of the constructor then runs a loop from zero up to sz, assigning each element of the original into the matching position of the new array.

The parameter is a const reference, so the copy constructor only reads from the original. The original object is never modified by the copy. Everything that changes during the operation belongs to the new object being built. Because each Vector gets its own array, the two objects are independent: changing an element of one does not change the corresponding element of the other.

Both functions copy elements and both allocate new memory, so they look alike on the page. The key difference is what already exists when they run. The copy constructor creates a brand new object, so there is no old state to clean up. Copy assignment acts on an object that already holds elements, so it must release those old elements before it finishes. The source identifies two important facts: copy assignment allocates new memory for the copy, and it deletes old elements before assigning new ones.

The order is deliberate. The copy has to read from the source before anything is released. If the source were the same object as the target, the copy loop would need the old elements, and deleting them first would leave the loop reading from storage that no longer belongs to the object. Keeping the allocate-and-copy steps ahead of the delete avoids that problem. This is general reasoning about the order, not a claim the source makes about a specific self-assignment case.

The line where a learner's expectation usually breaks is the delete[] line. Many readers assume that deleting something inside an assignment could also affect the source, since the source is the other object in the statement. The delete[] elem line acts on elem, which is a member of the object being assigned to. The source object's array is reached only through a.elem, and the function never deletes it. The result is that x changes and y does not.