14. Manipulating Memory

Advanced perspective: identity and access paths

A pointer is a typed value that may identify an object

Calling pointers powerful or dangerous is not yet a useful model. The decision at each use depends on more ordinary facts: which object is designated, whether that object is still alive, whether the access stays within its permitted extent and which other expressions can change it. An address-like value on the screen proves none of those facts by itself.

An object has a type, a value, a lifetime and storage. Applying the address-of operator to a suitable object can produce a pointer value that identifies it. A pointer object stores such a value and has its own type, value and lifetime. Pointer and pointee are not one thing. Changing the stored pointer value can select another object without moving either object, while changing the pointee through a dereference does not reseat the pointer.

Separate declaration, address formation and access

In int* pointer, the asterisk belongs to the pointer declarator. It is not the unary dereference operator being executed. In *pointer = 30, the asterisk is an expression operator. The same token appears in two grammatical roles, and confusing them produces a false picture of what the declaration does.

Forming a pointer is also different from dereferencing it. A null pointer value can be stored, copied and tested without identifying an object, but it cannot be dereferenced. A pointer one position past an array can participate in the limited operations for which that value is permitted, but it does not designate an element and must not be dereferenced. "Contains an address" is therefore weaker than "may be used for this access".

Trace every alias to the same state

#include <iostream>

void apply_bonus(int& score, int bonus) {
    score += bonus;
}

int main() {
    int score{20};
    int* scorePointer{&score};

    apply_bonus(score, 5);
    *scorePointer += 10;

    std::cout << score << '\n';
}

The original identifier, the reference parameter and the dereferenced pointer are three expressions that can designate the same score object at different points in execution. This is aliasing. There are not three integer objects and the pointer does not contain a private copy of 20.

A trace that follows only the spelling score misses two writes. When aliases are permitted, state reasoning must follow the object identity across every path that can designate it. This is why unrestricted writable aliases increase the evidence required: an apparently local read may observe a change made elsewhere through another name.

Null, uninitialised and dangling are different failures

A null check answers only the null question; it does not prove that a live object is designated. Once the storage duration of an automatic object ends, a pointer to that storage has an invalid pointer value. C++ does not require every later use of that invalid value, including an ordinary comparison, to have one portable result. An implementation may preserve a familiar non-null representation, but that observation would still provide no lifetime evidence.

Consider a pointer assigned &local inside a nested block. While local is alive, the pointer may designate it. At the closing brace, local's lifetime and automatic storage duration end, so the pointer value outside the block is invalid. Overwriting the pointer object with nullptr can prevent a later accidental use through that variable, but it cannot restore the ended object or repair aliases copied elsewhere.

The reverse misconception is equally important: setting one pointer to nullptr does not destroy an independently owned object. It changes that pointer object's value. Whether an object is destroyed depends on its lifetime and ownership mechanism, not on the disappearance of one non-owning access path.

References and pointers communicate different interface policies

A reference must be bound when it is initialised and cannot later be reseated to designate another object. In the C++ language model there is no ordinary null reference value. This makes T& suitable for an interface that requires an existing T and intends to use it through the alias.

A T* parameter can hold null, so an interface can use null by convention to mean that access is optional. That meaning is not supplied automatically by every pointer type. Pointers also represent positions, identity and non-owning views where null may be invalid. The function contract must say whether null is accepted and what happens when it is supplied.

Neither a raw pointer nor a reference carries an automatic ownership story. A raw pointer may historically participate in owning code, but the type does not reveal whether destruction is the caller's duty, the callee's duty or nobody's. Ownership mechanisms belong to the next lesson; here the necessary discipline is to avoid inventing ownership from punctuation.

Constness identifies which part this access path may change

Read from the declared name outwards: is the pointer itself const, is the pointed-to type const, or are both const? Constness of the pointee through one pointer is an access restriction, not a guarantee that the object is globally immutable. Another non-const alias may still be permitted to change it, and a later read through the const access path can observe that change.

An array conversion loses the bound

In many expressions, an array is converted to a pointer to its first element. This is not universal: contexts such as sizeof applied directly to the array and unary address-of treat the array differently. Once code has only a pointer to the first element, that pointer does not carry the number of elements.

Pointer arithmetic is defined only within the relevant array object and to its one-past boundary under the language rules. The one-past value can mark an end position, but dereferencing it is outside the array. A function that receives only int* must obtain the permitted count or end position from another trustworthy part of its contract. If pointer and count disagree, the pointer cannot correct the count.

A later lesson introduces bounded views such as std::span, which keep an access path and element count together. That design reduces the chance that two independent arguments drift apart, but it still does not own the elements or extend their lifetime. Bounds and lifetime remain separate obligations.

Remove an alias without pretending to remove the object

Trace this sequence on paper: int value{4}; int* p{&value}; int& r{value}; r += 3; *p *= 2; p = nullptr;.

Now place the definition of value in an inner block while keeping p outside. Mark the exact closing brace where the lifetime and automatic storage duration end. Do not use the invalid pointer value after that point. Instead, explain why even an implementation-defined non-null comparison result would not establish valid access, and identify which redesign would prevent the pointer from escaping the lifetime it depends upon. The exercise is complete only when object, pointer, aliases, bound and lifetime are separate facts in the explanation.

int* p{nullptr};

{
    int value{4};
    p = &value;
    // p may be dereferenced here.
} // value's lifetime and storage duration end; p's value is invalid.

// Do not compare or dereference the invalid value here.
p = nullptr; // Overwrite it without reading the old value.

int result{0};

{
    int value{4};
    int* p{&value};
    int& r{value};

    r += 3;
    *p *= 2;
    result = value;
} // value, p and r all cease to be usable here.

// result is an independent int value and may be used here.