Reference lifetime in C++ - Step-by-Step Execution

Concept Flow - Reference lifetime

Create object

↓

Create reference to object

↓

Use reference

↓

Object lifetime ends

↓

Reference becomes invalid

This flow shows how a reference is tied to the lifetime of the object it refers to. When the object is destroyed, the reference becomes invalid.

Execution Sample

C++

int& getRef() {
  int x = 10;
  return x;
}

int main() {
  int& r = getRef();
  return r;
}

This code returns a reference to a local variable which is destroyed after the function ends, causing a dangling reference.

Execution Table

Step	Action	Variable/Reference State	Notes
1	Enter getRef()	x = uninitialized	Local variable x created
2	Initialize x	x = 10	x assigned 10
3	Return reference to x	r -> x (10)	Reference r in main points to x
4	Exit getRef()	x destroyed	x goes out of scope, memory invalid
5	Use r in main	r -> invalid memory	Reference r is dangling
6	Return r	Undefined behavior	Using dangling reference causes error

💡 Function ends, local variable x destroyed, reference r becomes invalid

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5
x	uninitialized	10	destroyed	destroyed
r	none	points to x (10)	points to invalid	points to invalid

Key Moments - 2 Insights

Why is the reference 'r' invalid after getRef() returns?

Because 'x' is a local variable inside getRef(), it is destroyed when the function ends (see step 4 in execution_table). The reference 'r' then points to memory that no longer holds 'x', making it invalid.

Can a reference extend the lifetime of the object it refers to?

No, a reference does not extend the lifetime of the object. The object must exist independently. In this example, 'x' is destroyed at function end, so the reference 'r' becomes dangling.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of 'r' after step 4?

A Points to valid object with value 10

B Points to invalid memory (dangling reference)

C Is uninitialized

D Is null

💡 Hint

Check the 'Variable/Reference State' column for step 4 in execution_table

At which step does the local variable 'x' get destroyed?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look for when 'x destroyed' appears in the Notes column of execution_table

If 'x' was declared static inside getRef(), how would the execution_table change?

A Reference 'r' would still be invalid after step 4

B 'x' would be destroyed earlier

C 'x' would not be destroyed at step 4, so 'r' remains valid

D Reference 'r' would become null

💡 Hint

Consider object lifetime and when destruction happens in execution_table

Concept Snapshot

Reference lifetime in C++:
- A reference must refer to a valid object.
- References do NOT extend object lifetime.
- Returning reference to local variable causes dangling reference.
- Use only references to objects alive beyond reference use.
- Dangling references cause undefined behavior.

Full Transcript

This example shows how a reference in C++ is tied to the lifetime of the object it refers to. The function getRef() creates a local variable 'x' and returns a reference to it. When the function ends, 'x' is destroyed, but the reference 'r' in main still points to that memory. This makes 'r' a dangling reference, which is invalid and leads to undefined behavior. The execution table traces each step: creation of 'x', returning reference, destruction of 'x', and use of the invalid reference. Key points are that references do not extend object lifetime and returning references to local variables is unsafe. Understanding this helps avoid bugs related to invalid references.