15. Heap Memory

Advanced perspective: ownership is a responsibility, not a location

Knowing that an object is on the heap does not tell you who must keep it alive

Stack versus heap is a useful first distinction, but it is not the criterion that decides whether a program manages a resource correctly. Storage location tells us where an object is held and which broad lifetime rules apply. Ownership tells us which program object is responsible for ending that lifetime. A raw address establishes neither responsibility nor permission to keep using the object.

Suppose an allocation succeeds and returns an address. We can now draw at least three separate things: the allocated object, an owner that is responsible for it, and any number of aliases that can reach it. Copying an address creates another access path; it does not duplicate the allocated object. Destroying a pointer variable does not necessarily destroy the pointee. Deleting the pointee does not erase address values already copied elsewhere. Those values remain, but their apparent ability to identify the old storage is no licence to dereference them.

This is why a memory diagram should answer four questions at every important program point. If one answer is missing, the diagram is incomplete.

Trace exclusive ownership without merging owner and object

#include <iostream>
#include <memory>
#include <utility>

int main() {
    auto owner{std::make_unique<int>(42)};
    int* observer{owner.get()};

    std::cout << *observer << '\n';

    auto nextOwner{std::move(owner)};
    std::cout << *nextOwner << '\n';
}

The first line inside main creates one allocated int and one unique_ptr that owns it. The integer and the smart pointer are not the same object. owner.get() copies the stored address into observer; it does not transfer ownership and it does not create a second integer. The first output is therefore 42 because the owner is still alive and the observer designates its integer.

std::move(owner) does not move the integer to another allocation. It permits the ownership state held by one unique_ptr to be transferred into another. Afterwards, nextOwner owns the same integer and owner is empty. The raw observer still designates that integer, but only because the new owner continues to keep it alive. The address did not make the observer safe; the continuing lifetime did.

This trace also separates three operations that are easily confused. get() supplies a non-owning pointer while leaving the smart pointer responsible for cleanup. reset() can end the currently owned object's lifetime and may select a replacement. release() surrenders ownership and returns the raw pointer without destroying the object. The last operation is therefore not a sophisticated spelling of cleanup. Unless another owner immediately accepts that responsibility, it has merely converted an explicit obligation into an easy leak.

Choose the representation from the lifetime requirement

A changing amount of data does not by itself require an owning pointer. A std::vector<std::string> can grow, shrink, move and return by value while retaining ordinary ownership through its elements and storage. The useful question is not, "Will the data change size?" It is, "Does this program need a separately allocated identity with a lifetime that differs from the surrounding value?" If the answer is no, a value or container usually states the design with fewer obligations.

shared_ptr is not the safe default for an ownership question that nobody has answered. It expresses shared ownership, brings shared control state, and cannot by itself release a cycle of owning references. If an object needs to observe a shared resource without prolonging its lifetime, weak_ptr can represent that relationship and requires a checked attempt to obtain temporary shared ownership before access. The added machinery is justified when the lifetime really is shared. It is not a substitute for deciding the architecture.

RAII changes cleanup from a remembered action into a consequence

Manual allocation leaves a proof obligation across every exit path: normal return, early return, exception and later maintenance. The programmer must show that each successful acquisition reaches exactly one matching release and that no permitted use crosses that release. A comment saying "remember to delete" does not discharge the obligation. It merely documents the place where correctness depends upon memory.

RAII gives the obligation to an object whose destructor performs the release. Once construction succeeds, ordinary scope rules provide the path to destruction. A container destroys its elements, a unique_ptr destroys its pointee, and a resource wrapper can release a file, lock or operating-system handle. The useful mechanism is broader than heap memory: resource validity becomes an invariant of an owning object's lifetime.

This does not make every lifetime automatically correct. An observer can still outlive its owner. A shared_ptr cycle can still retain objects indefinitely. A destructor can still contain faulty release logic. RAII removes the need to repeat cleanup at every control-flow exit; it does not remove the need to design ownership and aliasing.

Manual ownership demands a type-level policy

Sometimes a low-level boundary genuinely requires direct acquisition and release. Confine that pair inside a type. Then decide whether that owner may be copied, moved, both or neither. A shallow copy of a raw owning pointer creates two apparent owners of one allocation and therefore makes duplicate release likely. Deleting copy operations can state exclusivity; implementing a real deep copy can give each object its own resource; move operations can transfer the one responsibility. Better still, if a standard container or smart pointer already implements the required policy, use it as a member and let the enclosing class follow the Rule of Zero.

Matching allocation and deallocation forms still matters at such a boundary: an array obtained with new[] requires delete[], while an object obtained with ordinary new requires ordinary delete. Yet a locally correct pair is only part of the proof. We must also know that the owner is unique where required, that every acquisition is adopted, and that no observer is used after the owner releases the resource.

Transfer task: follow the responsibility before following the address

Sketch one allocated controller, a unique_ptr named active, and two raw observers named cameraView and debugView. Both observers are obtained from active.get(). Ownership is then moved into reserve, after which active is tested and found empty. Finally, reserve.reset() is called.

At each step, record the owner, whether the controller is alive, and whether either observer may be dereferenced. Do not say merely that the addresses "still look valid". Explain the event that sustains or ends the controller's lifetime. Then change the design so that the debug system may safely report that the controller no longer exists without extending its lifetime. Your answer should state the interface contract, not just replace one pointer spelling with another.

#include <iostream>
#include <memory>
#include <utility>

class Controller {};

void report_controller(const std::weak_ptr<Controller>& view) {
    if (auto controller = view.lock()) {
        std::cout << "Controller exists\n";
        // Inspect *controller only while this local shared_ptr is alive.
    } else {
        std::cout << "Controller no longer exists\n";
    }
}

int main() {
    std::shared_ptr<Controller> active{
        std::make_shared<Controller>()
    };

    Controller* cameraView{active.get()};
    std::weak_ptr<Controller> debugView{active};

    auto reserve{std::move(active)};
    reserve.reset();
    report_controller(debugView);
}

Good memory management is visible before the program runs. The types and interfaces tell us who owns the resource, which operations transfer that responsibility, and which uses are only temporary observations. If correctness still depends upon everybody remembering an unwritten final delete, the design has postponed the difficult question rather than answered it.