C03: C++ values, references, ownership, and lifetimes

A. Prerequisites and observable goals#

Level: Degree core; memory safety before clever optimization.

B. The central question: who owns this resource, and how long does it exist?#

C++ makes object lifetime and resource management part of ordinary programming. A resource may be heap storage, a file, a lock, or a socket. An owner is responsible for releasing it. A nonowning reference or pointer lets code observe or modify an object without taking responsibility for its destruction. The important question is not whether a pointer looks intimidating; it is whether the pointed-to object still exists when it is used.

An object has a type, storage, a lifetime, and a value or state appropriate to its type. A value is the information an expression yields or an object represents; it is not the object's address. A declaration int b=a; creates a separate integer initialized from a. A declaration int& r=a; creates an alias to the same integer. Changing r changes a, not b. A pointer variable stores an address-like value and can be reassigned to refer elsewhere. The expression *p accesses the pointed-to object only when the pointer is valid for that access. A null pointer does not designate an object. The address operator &a obtains a pointer to a; the same character in a declaration introduces a reference. Context matters.

C. A small memory picture#

int a = 7;
int b = a;
int& r = a;
int* p = &a;
r = 9;
*p = 12;

Schematic: boxes represent objects, not a mandated byte layout or numeric address.

The reference does not create another integer. The pointer does not keep a alive. If a’s lifetime ends, a previously obtained pointer may remain as bits in another object, but dereferencing it is not valid. Returning a pointer or reference to a local automatic variable therefore creates a dangling result. A non-null check does not repair that lifetime defect.

D. RAII makes cleanup follow scope#

RAII—resource acquisition is initialization—associates resource ownership with an object’s lifetime. Construction acquires or establishes the resource; destruction releases it. Local owning objects are destroyed when their scope is left, including ordinary stack unwinding after an exception. The rule is stronger than remembering to call cleanup at the bottom of the happy path. It still has boundaries: abrupt process termination and some forms of abnormal termination are not ordinary scope exit. [CPP]

std::vector<T> owns a dynamic sequence and normally gives the safest starting representation for variable-sized contiguous data. std::unique_ptr<T> owns one object exclusively, and std::unique_ptr<T[]> owns an array. std::shared_ptr<T> expresses shared ownership with a control block, not automatic freedom from design problems; cycles of strong ownership can retain objects forever. Prefer clear single ownership unless shared ownership is actually part of the contract.

Constness constrains operations through an interface. A const Buffer& lets a function inspect an existing buffer without copying or modifying it through that reference. It does not prove that no other alias can modify the object, and it does not itself make concurrent use safe. A const int* points to an integer that cannot be modified through that pointer; int* const is a pointer whose own stored address cannot be changed. Read the declared type rather than treating all const placements as synonyms.

E. Copying and moving are distinct contracts#

Copying should create another value according to the type’s copy semantics. For an owning raw pointer, a naive copy duplicates the pointer but not the resource, producing two putative owners and a potential double deletion. Deleting copy operations prevents accidental duplication of exclusive ownership. Moving transfers ownership and leaves the source in a valid state specified by its type. std::move itself is a cast that permits move-aware operations; the selected constructor or assignment actually performs the transfer. Do not infer that an arbitrary moved-from standard-library object is empty unless its documented contract says so.

Our educational Buffer explicitly promises an empty moved-from state, implements it, and tests it. Its size and owning pointer must agree: a size of 5 with a null pointer would violate the class invariant. A hand-written move operation is justified here because the size is separate bookkeeping. In production, using std::vector<int> often gives a simpler design and avoids maintaining this invariant yourself.

F. Invalidation and performance choices#

An address into a vector is not permanently stable. A growth operation that reallocates storage invalidates pointers, references, and iterators into the old storage. Indexing again after the operation obtains access through the current container. Calling reserve can prevent reallocations within the reserved capacity, but it is not a universal lifetime guarantee across arbitrary modifications or destruction. A stable identifier is often more appropriate than a raw address across engine updates or asynchronous work.

Measure before replacing standard containers with a custom allocator or linked structure. Contiguity can improve locality, but the actual workload matters. Ownership reasoning comes before a benchmark: a faster use-after-free is not an optimization. Sanitizers help reveal selected invalid operations during executed paths; they are not a proof that every lifetime path is safe. [GCC]

G. Independent practice#

F foundation C standard course work T transfer S optional stretch L runnable lab or project. Attempt the complete set before opening its solutions.

H. Complete solutions: C03#

Compare the first step where your work differs. A corrected answer is not yet an independent success.

Open every solution

#pragma once
#include <cstddef>
#include <memory>
#include <stdexcept>
#include <utility>

// C03.05: one owner, explicit moves, and checked access.
class Buffer {
    std::size_t size_;
    std::unique_ptr<int[]> data_;
    static std::unique_ptr<int[]> allocate(std::size_t n) {
        if (n > 1'000'000) throw std::length_error("teaching size limit");
        return n ? std::make_unique<int[]>(n) : nullptr;
    }
public:
    explicit Buffer(std::size_t n) : size_(n), data_(allocate(n)) {}
    Buffer(const Buffer&) = delete;
    Buffer& operator=(const Buffer&) = delete;
    Buffer(Buffer&& other) noexcept
        : size_(std::exchange(other.size_, 0)), data_(std::move(other.data_)) {}
    Buffer& operator=(Buffer&& other) noexcept {
        if (this != &other) {
            data_ = std::move(other.data_);
            size_ = std::exchange(other.size_, 0);
        }
        return *this;
    }
    [[nodiscard]] std::size_t size() const noexcept { return size_; }
    int& at(std::size_t i) {
        if (i >= size_) throw std::out_of_range("buffer index");
        return data_[i];
    }
    const int& at(std::size_t i) const {
        if (i >= size_) throw std::out_of_range("buffer index");
        return data_[i];
    }
};

I. Retention and readiness#

Retrieve C01’s alias diagram and explain what changed when ownership became explicit. Advance when you can draw object lifetimes across a function call, distinguish std::move from a move operation, and repair a vector-invalidation design without sprinkling arbitrary copies or locks into it.