Memory Ownership, Pointers and RAII in C++

Learning objectives

• Distinguish stack lifetime, heap lifetime, pointer value and object ownership.
• Explain why returning or storing pointers to dead stack objects is unsafe.
• Identify unclear ownership in raw pointer code, especially T*& outputs.
• Choose safer alternatives: return by value, write into caller-owned references, containers or std::unique_ptr.
• Use warnings, sanitizers and minimal repros to catch leaks, dangling pointers and use-after-free bugs early.

Key vocabulary before you start

Example: unclear ownership versus RAII

The raw-pointer version relies on the caller remembering the matching delete; the RAII version makes ownership explicit.

void make_pointer(int*& out) {
    out = new int(99); // who deletes?
}

int* p = nullptr;
make_pointer(p);
delete p;

std::unique_ptr<int> make_owner() {
    return std::make_unique<int>(99);
}

auto owner = make_owner();

Visual model: ownership transfer and release

Use this model to decide whether a design owns, borrows or merely observes an object.

Stack and heap lifetimes

Stack objects usually live until their scope ends. Heap objects live until they are explicitly released, or until an owning RAII object releases them.

A pointer is only a value that stores an address. It does not, by itself, prove that the object at that address is alive.

Memory-safety review starts by asking what object exists, who owns it and which scope or owner controls its release.

Dangling pointers and stack escape

A pointer to a local stack object becomes invalid when that local object leaves scope.

Returning, storing or assigning such an address beyond the scope is a classic dangling-pointer bug.

The code can look plausible because the pointer contains an address, but the lifetime guarantee has already ended.

int* bad_pointer() {
    int local = 7;
    return &local; // dangling pointer
}

Safer ownership alternatives

Most pointer-returning designs can be replaced with clearer ownership patterns.

Return by value when the result is just a value. Write into a reference when the caller owns the destination. Return std::unique_ptr when heap ownership really must be transferred.

The goal is not to ban pointers. The goal is to make ownership and lifetime hard to misunderstand.

int make_value();                 // return by value
void write_into(int& out);       // caller keeps ownership
std::unique_ptr<int> make_heap_value(); // explicit heap owner

Diagnostics: catch bugs early

Enable sanitizers such as address and undefined-behaviour sanitizers, plus high warning levels, in debug builds.

Add assertions around risky dereferences, initialise pointers to nullptr, and make invalid states visible.

Prefer containers and algorithms that offer debug-mode bounds checks where practical.

Worked example: leak and dangle risk to RAII

The problem version mutates a caller's pointer and allocates on the heap. The caller must remember to release the object, and ownership is not visible at the call site.

The RAII version returns an explicit owner. The simplest version avoids heap allocation entirely and returns by value.

Professional C++ design prefers the simplest ownership model that satisfies the requirement.

void make_pointer(int*& out) { // mutates caller's pointer
    out = new int(99); // who deletes?
}

int* p = nullptr;
make_pointer(p);
delete p; // caller must remember (or leak)

#include <memory>

std::unique_ptr<int> make_owner() {
    return std::make_unique<int>(99);
}

auto p = make_owner(); // ownership clear, no manual delete

int make_value_simple() { return 99; } // return by value; move elision

Summary checklist

Prefer RAII: containers and smart pointers over raw new and delete.

Make ownership explicit: return by value, use references for required inputs or outputs, and use smart pointers for owned heap.

Do not hand out pointers to stack objects beyond scope. Avoid T*& unless you really need to mutate a caller's pointer.

Avoid mixing stack and heap carelessly; assume pointers can dangle unless proven safe.

Encapsulate allocations. Put new and delete in one place, usually constructors, destructors or established RAII wrappers.

Instrument with sanitizers and tests. Let tools and AI-assisted review catch memory mistakes early.

Later lessons can build on this with encapsulation patterns and smart pointers, including shared ownership.

Applied case lab

Applied task: spot the bug and fix it

Practise identifying dangling pointer risks, replacing raw ownership and choosing the smallest safe alternative.

Stage 1: read and classify

int*& g(int*& dst) {
    int local = 7;
    dst = &local; // returns pointer to dead stack object
    return dst;
}

int make_value() {
    return 7;
}

void write_into(int& out) {
    out = 7;
}

std::unique_ptr<int> make_heap_value() {
    return std::make_unique<int>(7);
}

Stage 2: trace or repair

int* arr = new int[100];
// ... use arr ...
delete[] arr; // easy to forget

std::array<int, 100> fixed{};

std::vector<int> dynamic(100);

Stage 3: justify the design

int* p = new int(99);
use(*p);
delete p;

int value = 99;
use(value);

// or, if heap ownership must be explicit:
auto p = std::make_unique<int>(99);
use(*p);

Quick checks

AI-augmented practice notes

Use these as prompts for disciplined support, not as permission to outsource judgement.

Assessment tasks

1. Find one raw pointer function and write an ownership trace for it.
2. Replace one manual new/delete pair with std::unique_ptr or a standard container.
3. Rewrite one pointer-output function as return-by-value or reference-output code.
4. Create a minimal dangling-pointer repro and describe how a sanitizer reports it.
5. Review one raw array and choose std::array or std::vector with justification.

Judgement questions