The Lifecycle of a Variable

Learning objectives

• Distinguish declaration, instantiation, assignment, release and deletion.
• Explain why automatic variables are released when their scope ends.
• Identify uninitialised reads, shadowing, dangling pointers and mismatched deletion.
• Use RAII and scope to make variable lifetimes easier to reason about.
• Trace construction and destruction order in a small C++ example.

Key vocabulary before you start

Example: a variable's basic lifecycle

This small example separates the stages that are often compressed into one line.

int x;      // declaration + instantiation
x = 5;      // assignment
// At the end of the enclosing scope, x is released and deleted.

int y = 5;  // declaration + instantiation + assignment

Visual model: lifecycle failure timeline

Most lifecycle bugs occur when the code reads after release, writes through the wrong owner or hides an earlier object.

The four lifecycle actions

Declaration associates an identifier with a type. Instantiation reserves memory for an object. Assignment writes a value into that object. Release and deletion end the object's lifetime.

These actions may appear separately or together. int x = 5; compresses declaration, instantiation and assignment into one source statement.

Release is normally implicit for automatic variables: when the closing brace of the block is reached, the variable's lifetime ends.

Explicit vs implicit memory management

For int x;, declaration is explicit because you name x and give its type. Instantiation and release are managed by the compiler for an automatic local object.

This implicit behaviour is valuable because the compiler can enforce scope rules. You cannot refer to a local name after its block has ended.

Heap allocation changes the burden. If you use new, you must ensure there is a matching and correctly timed release, which is why RAII containers and smart pointers are preferred.

int n = 3;           // automatic object
int* p = new int(n); // p is automatic; *p is heap allocated
*p += 1;
delete p;            // releases heap object
p = nullptr;

Common lifecycle errors

Novice errors usually happen at the boundary between lifecycle stages: reading before assignment, reading after release, returning references to dead locals, or deleting with the wrong form.

Shadowing can create a second variable with the same name in an inner scope. That is legal, but it can hide the variable you intended to initialise or update.

A good debugging session watches state transitions, not only final output. Ask which object is alive, which one has a meaningful value and who owns it.

int x;
std::cout << x; // unsafe: uninitialised read

int y = 42;
std::cout << y; // safe

int* make_bad() {
    int x = 42;
    return &x; // dangling pointer
}

int make_good() {
    return 42;
}

Use scope and RAII to make lifetime visible

RAII ties resource lifetime to object lifetime. The constructor acquires the resource and the destructor releases it.

Containers and smart pointers turn lifetime management into a property of scope rather than a manual checklist.

At Masters level, the goal is to design code where the safe lifetime is the obvious lifetime.

struct Trace {
    Trace(const char* name) : name(name) { std::cout << "make " << name << '\n'; }
    ~Trace() { std::cout << "drop " << name << '\n'; }
    const char* name;
};

int main() {
    Trace outer("outer");
    {
        Trace inner("inner");
    } // inner destroyed here
} // outer destroyed here

Applied case lab

Applied task: trace, fix and safeguard variable lifecycles

Practise identifying lifecycle stages and replacing fragile lifetime patterns with safer alternatives.

Stage 1: read and classify

#include <iostream>
using namespace std;

int main() {
    int n; // outer n
    if (true) {
        int n = 3;          // shadows outer n
        int* p = new int(n);
        *p += 1;
        cout << *p << "\n";
        delete p;
    }
    cout << n << "\n"; // outer n was never assigned
}

#include <iostream>

int main() {
    int outerCount = 0;
    {
        int innerCount = 3;
        auto value = std::make_unique<int>(innerCount);
        *value += 1;
        std::cout << *value << "\n";
    }
    std::cout << outerCount << "\n";
}

Stage 2: trace or repair

int* makeVal() {
    int x = 42;
    return &x;
}

int& pick(bool b) {
    int a = 1, c = 2;
    return b ? a : c;
}

int makeVal() {
    return 42;
}

std::unique_ptr<int> makeValOwner() {
    return std::make_unique<int>(42);
}

int pick(bool b) {
    return b ? 1 : 2;
}

Stage 3: justify the design

int* p = new int{5};
delete p;
std::cout << *p << "\n";

int* q = new int[3]{1, 2, 3};
delete q;

auto p = std::make_unique<int>(5);
std::cout << *p << "\n";

std::array<int, 3> q{1, 2, 3};

Quick checks

AI-augmented practice notes

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

Assessment tasks

1. Annotate one C++ function with lifecycle stages for every local variable.
2. Refactor one raw allocation into a container or smart pointer and explain the ownership change.
3. Add a short debugger trace showing where one variable becomes invalid.

Judgement questions