16. Scope and Extent

Advanced perspective: visibility does not establish validity

A name in scope is not evidence that an object may still be used

Braces make the ordinary local variable look simple. Its name becomes available after the declaration, its object is created during execution, and both cease to matter when control leaves the block. From that familiar case it is tempting to make one timeline do all the work. C++ requires three.

Scope governs where a declaration can contribute a name to lookup. Storage duration classifies the broad rules under which storage is retained. Lifetime is the interval during which an object exists, with its type and usable state, in some storage. These facts often align, but correctness depends upon knowing when they do not. A compiler accepting a name proves that lookup succeeded. It does not prove that a pointer or reference reached through that name still designates a live object.

The language defines automatic, static, thread and dynamic storage durations. A call stack and a heap are common implementation mechanisms, but they are not definitions of these language properties. Saying "it is on the stack" may help to sketch an implementation. It cannot replace the reasoning needed to decide whether a particular access is valid.

Separate the declaration, the name and the object

A declaration can introduce a name and arrange for an object to be created, yet name and object are not interchangeable. Shadowing demonstrates the first separation. An inner declaration can hide an outer name while the outer object remains alive. When the inner block ends, lookup can find the outer declaration again; the outer object has not been destroyed and recreated merely because its name was hidden.

A stored pointer demonstrates the more dangerous separation. The pointer variable can remain alive and its own name can remain in scope after the pointee's lifetime has ended. We may still assign nullptr to that pointer or destroy the pointer itself. What we may not do is treat the expired address as access to the former object. The living pointer object and the dead pointee are two different lifetime claims.

Returning a value creates a result, not a reference to an expired local

#include <iostream>
#include <string>

std::string make_label(int level) {
    std::string label{"Level "};
    label += std::to_string(level);
    return label;
}

int main() {
    const std::string label{make_label(7)};
    std::cout << label << '\n';
}

Inside make_label, the local name label can be used only within its scope after its declaration. Its local object is alive until the function completes. The return statement supplies a std::string value to initialise the caller's result. Named return value optimisation may construct the result directly in its destination; when that optimisation does not apply, the language's move or copy rules still produce a value result. None of these cases gives the caller a reference to the destroyed local object.

Change the return type to const std::string& and the reasoning fails. A reference value can escape the function, but the local string's lifetime still ends. The caller can possess a perfectly visible reference variable that refers to no live string. Visibility has survived; validity has not.

Every borrower carries a lifetime dependency

Raw pointers, references, iterators, std::string_view and spans can express non-owning access. Their low cost is not a lifetime guarantee. A borrower is usable only while the relevant owner keeps the target alive and while no operation invalidates the access relationship. The second condition matters because destruction is not the only invalidating event.

reserve() can sometimes make a particular sequence of vector insertions avoid reallocation, but it is not a general repair for an undocumented borrow. The required capacity, every relevant mutation and the duration of the borrow must still be known. If the relationship crosses an interface or is stored for later use, express the lifetime expectation plainly enough that a caller can satisfy it.

Temporary lifetime extension is precise, not contagious

Binding a suitable reference directly to a temporary can extend that temporary's lifetime in specified initialisation contexts. This is a rule attached to the particular binding, not a property that travels through any later reference, return statement or view. Returning a reference to a temporary created inside the function does not make the caller's reference a new extension. Constructing a non-owning view from temporary storage does not turn the view into an owner.

When reviewing such code, do not ask only whether a const reference appears. Identify the full expression that created the temporary, the exact reference initialisation, and the point at which the applicable rule ends the temporary's lifetime. If that chain cannot be shown, the reassuring keyword is doing more emotional work than technical work.

A move changes state or ownership, not the fact that the source object lives

After a valid move, the source object has not gone out of scope and its lifetime has not automatically ended. Its state is determined by the type's contract. Standard-library types are generally required to remain valid but may have an otherwise unspecified state after being moved from, unless a stronger guarantee applies. User-defined types must be judged by their own valid operations and invariants.

This distinction prevents two opposite mistakes. Assuming that the old value remains unchanged can lead to faulty use. Assuming that the object is dead can lead to skipping required destruction or denying operations that its contract permits, such as assignment of a new value. Mark the move as a state transition. Do not mark it as an imaginary closing brace.

Long lifetime does not justify wide visibility

A static local provides the useful counterexample to the idea that scope and lifetime should always be widened together. Its name remains local to the function, while the object has static storage duration and persists across calls after initialisation. This can encapsulate persistent state, but it also means that one call can affect the next. Narrow scope limits where the name can be used; it does not make the stored state transient.

Dynamic storage provides another separation. A local owning smart pointer may transfer ownership to a caller before its own name disappears. The allocated object's lifetime continues because another owner accepts the responsibility, not because the original local name somehow remains in scope. Conversely, losing the last owning handle without release can strand a resource even though no useful name remains. No name is not the same as no object.

Transfer task: prove the final use, not just the final name

Consider a function that creates a std::vector<std::string>, stores a std::string_view of its first element, moves the vector into a result object, appends another element to that result, and finally prints through the saved view. Draw the scope of each name, the lifetime of the vector and strings, and the period during which the view is valid.

You are not being asked to guess whether one run happens to print the expected characters. Identify the first operation whose specified effects might invalidate the view, and explain why the continued existence of the result vector does or does not settle the matter. Then redesign the interface in two ways: once by returning an owning string value, and once by keeping a non-owning view whose permitted lifetime is confined to a caller-controlled operation. State the cost and contract of each answer.

struct BuildResult {
    std::vector<std::string> values;
    std::string firstValue;
};

BuildResult build_values() {
    std::vector<std::string> values{"first"};

    BuildResult result;
    result.firstValue = values.front();
    result.values = std::move(values);
    result.values.emplace_back("second");
    return result;
}

void print_first(const std::vector<std::string>& values) {
    if (values.empty()) {
        return;
    }

    const std::string_view first{values.front()};
    std::cout << first << '\n';
}

void finish_and_print(std::vector<std::string>& result) {
    result.emplace_back("second");
    print_first(result);
}

Scope is a rule about names. Lifetime is a rule about objects. Storage duration is a rule about storage. Safe C++ begins when those statements remain separate in the explanation and are deliberately connected in the design.