Returning references from functions

1. Introduction

Sometimes students hear the phrase “a function returns a reference” for the first time and honestly imagine some magic like “teleporting a variable through the monitor.” In reality it's much more prosaic: returning a reference means returning not a new object, but access to an already existing object. In other words, “returning another name.”

Returning a value (T) is like handing someone a copy of a document (or moving the value, but here we emphasize the “separate entity” model). Returning a reference (T& or const T&) is like giving someone a pass to an archive where the original is kept. The pass is convenient, but if the archive burns down (the object is destroyed), the pass remains but access to the content is gone.

The most common reasons to return a reference are:

1. to avoid copying a large object (for example, std::string, std::vector),
2. to give the caller the ability to modify a specific object that lives somewhere “outside”.

And here the risk zone begins: a reference does not own the object. It simply points: “there it is.” If “there it is” disappears — the reference becomes dangling, and the program turns into a lottery.

2. What T& and const T& mean as a return type

A reference return type has a very concrete meaning, and that meaning is not about syntax but about promises between the function author and its user.

When you write T&, you effectively say: “I will return a reference to an object that definitely exists after the function returns, and you can modify the object through this reference.”

When you write const T&, you say: “I will return a reference to an object that definitely exists after return, but you cannot modify it through this name — only read.”

In both cases the key phrase is “the object definitely exists after return.” The compiler cannot prove for you that you are not lying (sometimes it may warn, but there is no guarantee). Therefore returning references is a place where the programmer must mentally track object lifetimes.

C++ even has separate standardization discussions and fixes related to “lifetimes of temporaries bound to references” and “full-expression and temporaries bound to references” — the topic is really subtle, and not because you are “stupid”, but because the language is historically complex.

Practical rule about lifetime

If a function returns a reference, the object referred to must be created not inside that function, or must have a “very long lifetime” (for example, static), or must belong to the caller and be passed into the function by reference/pointer.

Otherwise you will almost certainly create a dangling reference: the reference remains, but the object is gone.

To avoid speaking abstractly, let's continue with our educational console project. Let it be a simple “task tracker” (a list of tasks) that stores tasks in a std::vector.

3. Minimal TaskTracker model: the Task type and the task container

Now we need a minimal data model so examples don't look like “spherical references in a vacuum.” Imagine that somewhere in the project there is such a struct:

#include <string>

struct Task {
    int id = 0;
    std::string title;
    bool done = false;
};

And in main() we store tasks like this:

#include <vector>

int main() {
    std::vector<Task> tasks;
    // ...
}

The focus of today's lecture: write functions that find a task and return a reference — and do it safely.

4. Safe ways to return a reference

Return a reference to a parameter

This is the “cleanest” return-by-reference scenario. The function does not create the object; it receives it from the caller and returns it as a reference, sometimes after some check or selection.

Example: a function that “returns the larger of two numbers” as a reference. Yes, it sounds odd, but it is a classic demonstration.

#include <iostream>

int& max_ref(int& a, int& b) {
    return (a > b) ? a : b;
}

int main() {
    int x = 10;
    int y = 20;

    max_ref(x, y) = 999;
    std::cout << "x=" << x << " y=" << y << "\n"; // x=10 y=999
}

Why is this safe? Because x and y are created in main() and live at least until the end of main(). The function max_ref does not create new objects; it merely selects one of the already existing ones.

Important nuance: such a function will not accept temporaries, because a parameter of type int& cannot bind to a temporary. This is good: the compiler protects us from attempting to return a reference to something that lives “a single moment.”

Return a reference to an element of a container passed in from outside

Now we approach our task tracker. We want to find a task by id and return a reference to it so the caller can change done or title.

We'll write a function that returns Task&, but it assumes the task definitely exists. This is an important contract: if the task “definitely exists” — great; if not, we must either abort or choose a different design.

Here is a "dangerous-educational" sketch (don't do this in production, but it's useful to see the problem):

#include <vector>

Task& find_task_by_id(std::vector<Task>& tasks, int id) {
    for (Task& t : tasks) {
        if (t.id == id) return t;
    }
    return tasks.front(); // educational hack: don't do this
}

Why can returning a reference be safe? Because t is a reference to an element inside tasks, and tasks is owned by the caller. We return a reference to a part of an object that exists outside the function.

But why is this code still bad? Because if the element is missing we return “something wrong,” and that will be a logical error: you'll change the wrong task. This is not a “reference error,” it's a contract error.

If a task may be absent, the honest option is to return a pointer Task* to express a nullable contract via nullptr:

#include <vector>

Task* find_task_ptr(std::vector<Task>& tasks, int id) {
    for (Task& t : tasks) {
        if (t.id == id) return &t;
    }
    return nullptr;
}

Usage:

#include <iostream>
#include <vector>

int main() {
    std::vector<Task> tasks{{1, "Read C++", false}, {2, "Drink tea", false}};

    if (Task* t = find_task_ptr(tasks, 2)) {
        t->done = true;
    }

    std::cout << tasks[1].done << "\n"; // 1
}

Now note: we started talking about returning references, but moved to pointers. That's fine: the idea is simple — “you can return T& only if the function guarantees the object exists.”

If you want exactly Task&, make the contract strict: “if not found — terminate the program.” It's crude but honest (and acceptable in educational code):

#include <iostream>
#include <vector>

Task& find_task_or_die(std::vector<Task>& tasks, int id) {
    for (Task& t : tasks) {
        if (t.id == id) return t;
    }
    std::cout << "Task not found, id=" << id << "\n";
    std::exit(1);
}

Usage:

#include <iostream>
#include <vector>

int main() {
    std::vector<Task> tasks{{1, "Read C++", false}, {2, "Drink tea", false}};

    Task& t = find_task_or_die(tasks, 2);
    t.done = true;

    std::cout << tasks[1].done << "\n"; // 1
}

This approach does the main thing: it turns “dangerous uncertainty” into a “hard but clear contract.”

Careful: a reference to a std::vector element can go stale

When you return a reference to an element of a std::vector, remember: as long as the vector is not structurally modified, the reference is valid. But if you add or remove elements, call erase, or do push_back that triggers reallocation — the reference may become invalid.

We won't dive into a detailed invalidation table now (that's a separate big topic), but the life lesson is simple: a reference to a container element is not a “permanent ticket,” it's a “pass valid until the administration moves to another building.”

Therefore returning a reference to a container element is safe only if the caller will not store it “forever” and then mutate the container.

Return a reference to a static object

Sometimes you need to return a “shared object” that exists for the whole program run. Inside the function you can create a static variable: it is initialized once and lives until program termination.

Example: the application name (a constant string).

#include <string>

const std::string& app_name() {
    static const std::string name = "TaskTracker";
    return name;
}

Usage:

#include <iostream>
#include <string>

int main() {
    std::cout << app_name() << "\n"; // TaskTracker
}

Why is this safe? Because name resides not on the function stack but in static storage: it does not disappear when app_name() returns.

Why not overuse this? Because static is global state. It's convenient, but if you start storing “everything” that way, you'll end up with a program where everything is tightly coupled and debugging is unpleasant. As a technical trick, though — “return a reference to an object that definitely lives long” — it's an honest option.

5. Anti-patterns: how to get a dangling reference

Returning a reference to a local variable

This is a classic. If you remember only one thing from this lecture — let it be this.

Local variables live on the stack. Once the function returns — its stack frame is destroyed. So you must not return a reference to a local object.

int& bad() {
    int x = 123;
    return x; // forbidden magic: x dies after bad() returns
}

Even if the compiler warns (it often does), sometimes people suppress warnings or ignore them, and later wonder: “why does it sometimes work, sometimes print 0, and sometimes crash.”

This is the typical dangling reference: the reference remains, but the object does not. The behavior is not required to be predictable.

Returning a const T& to a temporary object from return

This trap appears often because you already know: “a const reference can bind to a temporary.” And it can — but there is a subtlety: lifetime extension of a temporary works when the temporary is bound to a reference variable (for example, const T& ref = ...;) within its scope. When you return a reference you are returning it outside that scope, and that “reference variable” no longer exists.

So this code is bad:

#include <string>

const std::string& bad_title() {
    return std::string("temporary"); // temporary string dies at the end of the return expression
}

Correct variants here are usually: either return std::string by value (and that's fine!), or return a reference to an object that lives longer (for example, a static const std::string) if you really need a const&.

Returning a reference to an element of a local container

This may look “smarter,” but it breaks for the same reason: the container is local and dies when the function returns, and its elements die with it.

#include <vector>

int& bad_elem() {
    std::vector<int> v{10, 20, 30};
    return v[1]; // v dies, the element dies, the reference remains
}

If you catch yourself wanting to write something like this in real code, the almost always correct answer is: return a value, or pass the container from outside, or keep the container alive longer (for example, as global/static — but that's an architectural responsibility).

6. Cheat sheet: what to return from a function

Now we want a cheat sheet “what to choose.” Let's make a small table so the brain has something to latch onto.

T

T&

const T&

T*

Important: sometimes students think “returning by value is always slow.” In modern C++ it's often fine and readable to return std::string or even std::vector by value. Returning a reference is not an “optimization”; it's a change of meaning: you're returning access to someone else's object.

7. Practice for TaskTracker: find and mark a task

Let's assemble a small scenario: the user entered an id, and we mark the task as done.

Option A: “task is required” — return Task&.

#include <iostream>
#include <vector>

Task& find_task_or_die(std::vector<Task>& tasks, int id) {
    for (Task& t : tasks) if (t.id == id) return t;
    std::cout << "No task with id=" << id << "\n";
    std::exit(1);
}

int main() {
    std::vector<Task> tasks{{1, "Read C++", false}, {2, "Drink tea", false}};
    find_task_or_die(tasks, 2).done = true;
    std::cout << tasks[1].done << "\n"; // 1
}

Here the nice part is the chaining: we found the task and immediately modified its field — very readable.

Option B: “task may be absent” — return Task*.

#include <iostream>
#include <vector>

Task* find_task_ptr(std::vector<Task>& tasks, int id) {
    for (Task& t : tasks) if (t.id == id) return &t;
    return nullptr;
}

int main() {
    std::vector<Task> tasks{{1, "Read C++", false}, {2, "Drink tea", false}};

    if (Task* t = find_task_ptr(tasks, 42)) {
        t->done = true;
    } else {
        std::cout << "Nothing to mark\n"; // Nothing to mark
    }
}

This is also an honest design: the type Task* forces you not to forget about “not found.”

8. Mini lifetime diagram

To avoid relying only on intuition, it's useful to draw a small stack diagram in your head.

Imagine:

const std::string& f() {
    std::string s = "hello";
    return s; // bad
}

Lifetime model (very rough):

main():
  calls f()
    f():
      [stack frame f]
      s = "hello"   <-- lives here
      return s      <-- you carry the "address" outside
    end f():
      stack frame f destroyed
      s destroyed   <-- object gone
  you have a reference that points "somewhere in the past"

This is why dangling references are so nasty: they are not required to fail immediately. They may “work” on your machine and crash on another. They may break only in Release. They may even break only on Fridays (the most mystical bug — “it breaks when the manager walks by my desk”).

9. Typical mistakes when returning references

Mistake #1: returning T& to a local variable.
This is the most common and most dangerous mistake: a local variable dies when the function returns, but the reference remains. Even if it “seems to work,” this is not success — it's just a lucky memory coincidence, and you haven't been caught yet.

Mistake #2: returning const T& to a temporary object created inside return.
Knowing that “a const reference can bind to a temporary” often leads into a trap: you think the lifetime will be extended, but when returning outward there is nothing left to extend. The temporary will be destroyed quickly, and the reference will dangle.

Mistake #3: returning a reference to an element of a local container.
A container (for example, std::vector) is also an object. If it is local, it dies along with its elements. So returning T& to v[i] where v was created inside the function is the same anti-pattern in fancier wrapping.

Mistake #4: returning T& where the object may not exist.
For example, “find a task by id.” If the task can be absent, T& forces you either to lie about the contract, or to return “some random other task,” or to abort. Usually for “may be absent” a T* with nullptr is more suitable because the type nudges you to check.

Mistake #5: storing a returned reference to a std::vector element and then mutating the vector.
Even if the reference was valid at the moment of return, the container may change its internal storage when you add/remove elements. Then the reference to the element becomes invalid. In simple code it's better to use the reference briefly: get it — perform the action — forget it, rather than keep it around.

1

Task

C++ SELF, level 40, lesson 1

Locked

The maximum lever

The maximum lever

Open

1

Task

C++ SELF, level 40, lesson 1

Locked

Channel switcher

Channel switcher

Open

1

Task

C++ SELF, level 40, lesson 1

Locked

Safe access

Safe access

Open

1

Task

C++ SELF, level 40, lesson 1

Locked

Living reference

Living reference

Open