UpdatedAug 4, 2026

Object Lifetime and Dangling References

Question Variations

"What is a dangling reference in C++?"
"Why is returning a reference to a local variable undefined behavior?"
"Do references extend object lifetime?"
"How can a view type become invalid?"

Why This Is Asked

Many difficult C++ bugs come from using an object after its lifetime has ended. This question tests whether you can distinguish ownership from access, recognize temporary and local lifetimes, and design APIs that do not return dangling pointers or references.

Key Concepts

A reference or raw pointer does not own an object or extend its lifetime.
Returning a reference or pointer to a local object creates a dangling result.
Temporary lifetime extension is limited and should not be relied on indirectly.
RAII owners such as values and smart pointers make lifetime explicit.

Question Variations

“What is a dangling reference in C++?”
“Why is returning a reference to a local variable undefined behavior?”
“Do references extend object lifetime?”
“How can a view type become invalid?”

Answers by Technology

+ Add Variant

C++Improve this answer ✏️

Expected Answer (C++23)

An object’s lifetime is the period in which it is a valid object of its type. Pointers and references only provide access; they do not keep an object alive. Using a pointer or reference after its target is destroyed is undefined behavior, even if the memory still appears unchanged.

Do not return references or pointers to local variables. Return an owning value, transfer ownership with a smart pointer when heap allocation is required, or require the caller to own the referenced object for a clearly documented duration.

#include <string>

std::string make_message() {
    std::string message = "ready";
    return message; // Returned by value; copy elision or a move handles transfer.
}

int main() {
    const auto message = make_message();
    return message == "ready" ? 0 : 1;
}

Returning const std::string& from make_message would return a dangling reference because the local string is destroyed as the function returns.

Why It Matters

Lifetime errors cause crashes, data corruption, and security vulnerabilities that may appear only under certain builds or workloads. Clear ownership boundaries make C++ APIs predictable and safe to compose.

Common Mistakes

Returning a reference to a local object: The local is destroyed before the caller uses the reference.
Keeping a pointer or iterator after a container reallocation: Operations such as vector growth can invalidate it.
Assuming a non-owning view extends data lifetime: Types such as std::string_view and std::span require another object to keep the storage alive.

Follow-up Questions

When should a function return by value? (Answer: When it produces a new result that the caller should own; modern C++ usually makes this efficient.)
What keeps an object alive behind a shared_ptr? (Answer: The object’s lifetime continues while at least one owning shared_ptr remains.)