const T&: чтение без копии и привязка к временным

1. Зачем нужен const T&

Когда вы только начинаете писать функции, хочется выбирать параметры по принципу «лишь бы компилировалось». Но довольно быстро выясняется, что копирование больших объектов (строк, векторов, структур с кучей полей) может быть дорогим, а T& — слишком «сильный» контракт: он обещает, что функция может менять аргумент. const T& — это золотая середина: без копии, но только чтение, плюс он дружит с временными значениями.

Очень практично думать так: const T& — это «я возьму ваш объект в аренду на время вызова и обязуюсь ничего в нём не менять».

Что означает const в const T&

Важно начать с маленькой подводки: слово const в C++ часто пугает новичков тем, что «всё становится запретным». На самом деле const чаще всего не про запрет, а про контракт. Вы говорите компилятору (и человеку, читающему код): «через это имя я не буду менять объект». И если вы случайно попробуете — компилятор вас остановит, как охранник в музее: «руками не трогать».

Ключевой смысл:

const T& — это ссылка на T, но через эту ссылку нельзя менять объект.

При этом объект может быть и не const сам по себе.

Посмотрим на мини-пример:

#include <iostream>

int main() {
    int x = 10;
    const int& r = x;   // r — “читающий псевдоним” x

    std::cout << r << '\n'; // 10
    // r += 1; // ошибка компиляции: нельзя менять через const-ссылку
}

Здесь x вообще-то обычный int, его менять можно. Но конкретно через имя r — нельзя. Это и есть контракт.

К чему можно привязать const T&

Ссылки в C++ привязываются по правилам (их часто называют binding rules). И эти правила — одна из причин, почему const T& встречается в реальном коде чаще, чем просто T&.

Подводка такая: T& — «редактирующая» ссылка, а const T& — «читающая». Значит, const T& разрешают привязывать в большем количестве случаев, потому что это безопаснее: вы не сможете изменить то, что менять нельзя или не стоит.

Мини-таблица совместимости

Это — «интуитивная» версия правил, достаточная на нашем уровне. В стандарте есть формальные формулировки, и даже отдельные обсуждения вокруг “temporaries bound to references” и “lifetime extension”, потому что тема тонкая.

Пример: T& не привязывается к const T

#include <string>

int main() {
    const std::string name = "Alice";

    // std::string& bad = name; // ошибка: нельзя дать “изменяющую” ссылку на const-объект
    const std::string& ok = name; // норм: я обещаю не менять
    (void)ok;
}

Логика тут простая: если бы std::string& привязывался к const std::string, вы могли бы изменить «константную» строку — это ломает саму идею const.

2. Временные объекты и продление времени жизни

Что такое временные объекты и почему const T& с ними дружит

Временные объекты — это такие «однодневки» C++: они появляются как результат выражения и обычно исчезают очень быстро. Новички часто не замечают их существование, потому что у них нет имени. Но компилятор-то их создаёт, и правила времени жизни тут реально важны.

Примеры временных значений:

• результат a + b (для чисел),
• результат std::string("Hi"),
• результат конкатенации строк s1 + s2.

Пример: const int& к временному числу

#include <iostream>

int main() {
    const int& answer = 42;      // 42 — временное значение (temporary)
    std::cout << answer << '\n'; // 42
}

Почему так можно? Потому что answer не может изменить временный объект (он const), а значит, это безопасно.

С int& так нельзя:

int main() {
    // int& r = 42; // ошибка: нельзя привязать T& к временному
}

Продление времени жизни временного

Давайте аккуратно: временные объекты обычно живут недолго. Часто — до конца «полного выражения» (в разговорной речи: до конца строки/выражения). Но есть важное правило: если временный объект привязан к переменной типа const T&, то время жизни временного продлевается до конца области видимости этой ссылки.

Это правило — одна из ключевых причин, почему const T& так популярен. И да, вокруг него есть отдельные тонкости и обсуждения в стандарте (например, про “lifetime extension of references” в разных ситуациях).

Пример: временная строка «живёт дольше», чем кажется

#include <iostream>
#include <string>

int main() {
    const std::string& s = std::string("hello"); // временный std::string
    std::cout << s << '\n'; // hello
}

Если бы не правило продления, это выглядело бы как «ссылка на исчезающую строку», но здесь всё хорошо: временный объект живёт столько же, сколько живёт s.

Схема времени жизни

flowchart LR
    A["Создали temporary: std::string('hello')"] --> B["Привязали к const std::string& s"]
    B --> C["temporary живёт до конца scope переменной s"]
    C --> D["Выходим из scope: s уничтожается, temporary тоже"]

Если mermaid у вас в среде не рендерится — не страшно. Смысл простой: ссылка s как будто «держит» временный объект живым, но только в пределах своей области видимости.

Временные и параметры функций: где граница безопасности

Сейчас будет честное уточнение, чтобы не родить опасный миф «любая const-ссылка делает всё бессмертным». Когда const T& — это параметр функции, временное значение, переданное в вызов, живёт достаточно долго, чтобы функция спокойно отработала, но это не означает, что вы можете вынести ссылку наружу и пользоваться ею после.

На практике запоминаем аккуратную модель: «параметр const T& безопасен для передачи временных, потому что временный переживает вызов функции». А дальше (после выхода из функции) — уже нет никаких гарантий.

Вот безопасный пример:

#include <iostream>
#include <string>

void print_line(const std::string& text) {
    std::cout << text << '\n';
}

int main() {
    print_line("Hi!"); // строковый литерал превращается во временный std::string
}

Здесь всё отлично: временная строка существует на время вызова print_line.

Но если попытаться внутри print_line «сохранить ссылку куда-то глобально», вы очень быстро окажетесь в мире висячих ссылок. Мы эту тему подробно разберём в лекциях про возврат ссылок и про время жизни. Сегодня — только вводная, без погружения в самые злые ловушки.

3. Практика: параметры функций и auto

const T& как основной читающий параметр

Самая частая реальная ситуация: вы пишете функцию, которая должна прочитать строку, вектор или вашу структуру-модель, но не должна её менять. Если вы примете параметр по значению, вы создадите копию. Если примете T&, вы разрешите менять объект (и запретите передавать временные значения). Поэтому типичный выбор — const T&.

Это настолько распространённо, что в C++ есть «народное правило»: «если функция не должна менять объект и объект тяжёлый — принимай const&». Для int это обычно не нужно, а для std::string и std::vector — почти всегда уместно.

Пример: длина строки без копии

#include <iostream>
#include <string>

std::size_t len(const std::string& s) {
    return s.size();
}

int main() {
    std::string name = "Alice";
    std::cout << len(name) << '\n';    // 5
    std::cout << len("Hello") << '\n'; // 5
}

Обратите внимание: len("Hello") работает именно потому, что параметр — const std::string&. С std::string& так бы не вышло.

Пример из приложения: печать Task

Представим, что к этому моменту курса у нас уже есть маленькое консольное приложение «Список задач» (не потому что все обязаны писать TODO-лист, а потому что он не сопротивляется и не убегает).

У нас есть модель задачи:

#include <string>

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

Теперь мы хотим печатать задачу на экран. Печатать — значит читать поля, но не менять задачу. И это прямой кандидат на const Task&.

#include <iostream>
#include <string>

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

void print_task(const Task& t) {
    std::cout << "#" << t.id << " " << t.title;
    std::cout << (t.done ? " [done]\n" : " [todo]\n");
}

int main() {
    Task a{1, "Read about const references", false};
    print_task(a); // #1 Read about const references [todo]
}

Почему это хороший стиль?

• Во‑первых, мы не копируем Task (а внутри неё есть std::string, копировать который может быть заметно дороже, чем int).
• Во‑вторых, по сигнатуре видно: функция не имеет права менять задачу. То есть если вы случайно добавите внутрь t строку вроде t.done = true;, компилятор вас остановит.

Частая «учебная» ошибка: принять Task по значению

void print_task(Task t) { // копия!
    // ...
}

Так писать не запрещено, и на маленьких примерах это «работает». Но это как ездить в магазин за хлебом на грузовике: можно, но странно.

Нюанс с auto: как не сделать лишнюю копию

Иногда вы пишете красиво:

auto x = something();

И думаете, что x — это «ссылка». Но auto без & делает копию, если выражение справа — ссылка. Это не ошибка языка — это вы просто попросили копию.

В контексте const T& хорошая привычка такая: если вы хотите «просто почитать, без копий», то чаще всего вам нужен const auto&.

#include <iostream>
#include <vector>

int main() {
    std::vector<int> v{10, 20, 30};

    const auto& first = v[0]; // читаем без копии (хотя int и так дешёвый)
    std::cout << first << '\n'; // 10
}

Да, для int это не критично. Но для std::string и ваших моделей — уже очень даже.

4. Типичные ошибки при работе с const T&

Ошибка №1: пытаться изменить объект через const T& и злиться на компилятор.
Компилятор не вредничает — он буквально выполняет вашу просьбу. Если параметр const Task& t, то вы обещали «не менять». Если по логике программы менять всё-таки надо, контракт должен быть другим: Task& (изменяю обязательно) или Task* (изменяю, если указатель не nullptr), но это уже отдельный разговор про дизайн API.

Ошибка №2: думать, что const T& всегда продлевает жизнь временного «навсегда».
Продление времени жизни работает в конкретных сценариях, в частности когда временный объект привязывается к переменной const T& в инициализации. Это правило существует, но оно не превращает временные объекты в бессмертных — у них всё равно есть границы жизни, просто иногда они шире, чем «до конца строки».

Ошибка №3: хранить const T& дольше, чем живёт объект, на который он ссылается.
const не делает ссылку «безопасной» по времени жизни. Она всего лишь запрещает изменение. Если объект уничтожен, ссылка превращается в висячую — и это уже не про «можно/нельзя менять», а про «объекта больше нет». Эту мысль особенно важно держать в голове, когда вы храните ссылки на элементы контейнеров или на локальные переменные из других областей видимости.

Ошибка №4: ставить T& везде по привычке, а потом удивляться, что не принимаются временные значения.
Если функция не должна менять аргумент — лучше сразу писать const T&. Тогда вы сможете передавать и обычные переменные, и const-объекты, и временные значения. Это делает API дружелюбнее и проще в использовании, особенно в утилитных функциях вроде печати, проверки, форматирования.

Ошибка №5: «оптимизировать» всё подряд через const&, даже маленькие типы.
Для int, double, char передача по значению обычно проще и не хуже. const& — не магическая кнопка «ускорить программу», а инструмент для случаев, где копирование реально ощутимо или где вам важно принимать временные значения без отдельной перегрузки. И да, иногда const& используют и для маленьких типов ради единообразия, но это уже вопрос стиля и договорённостей команды.