C++ с нуля: большая шпаргалка по синтаксису, ООП, STL и современным стандартам

C++ — компилируемый язык программирования с ручным контролем ресурсов, статической типизацией и поддержкой нескольких парадигм: процедурной, объектной, обобщённой и функциональной.

Простое определение для самых начинающих. C++ — это язык, на котором вы пишете инструкции для компьютера, при этом компьютер проверяет ваши инструкции заранее (до запуска), требует от вас аккуратности с памятью и даёт несколько стилей программирования на выбор. Это как разница между письмом по строгому юридическому шаблону (любая ошибка делает документ недействительным) и дружеской запиской (что-то поймут, что-то нет).

Аналогия из жизни, чтобы запомнить раз и навсегда. C++ — это «инструмент штукатурщика» (мастерок, уровень, правило), а не «робот-пылесос»: он даёт вам полный контроль над тем, что происходит в памяти и процессоре, но взамен требует аккуратности. Робот-пылесос всё делает сам, но вы не контролируете, как именно он убирает; мастерок требует мастерства, но позволяет выровнять стену идеально. Python и Java — это роботы-пылесосы (автоматическая сборка мусора, динамические типы, интерпретация), C++ — это профессиональный инструмент. Почему так: язык создавался в начале 1980-х, когда каждый байт памяти и каждый такт процессора были на счету — поэтому в нём нет «автопилотов», зато есть прямой доступ к «рулю».

Для кого эта шпаргалка и зачем она нужна. Если вам нужна шпаргалка по C++, которая проведёт от первой программы до C++20/23, — вы её открыли. Здесь собран не учебник для первоклассника, а плотный справочник для тех, кто уже написал свой Hello, World! и хочет разобраться глубже. Практический совет: если вы совсем новичок — начните с любого онлайн-курса по основам C++, а эту шпаргалку используйте как справочник «второго уровня», когда нужно быстро освежить в памяти синтаксис или найти подводный камень.

Краткая история языка, чтобы понимать, откуда что растёт. Созданный Бьёрном Страуструпом как «C с классами» в начале 1980-х в Bell Labs, за сорок лет язык получил шаблоны (1980-е–90-е), исключения (1990-е), STL — стандартную библиотеку контейнеров и алгоритмов (1994, Александр Степанов), семантику перемещения (C++11, 2011), constexpr (вычисления на этапе компиляции, C++11/14/20), concepts (ограничения на шаблоны, C++20) и ranges (новый способ работать с контейнерами, C++20). Важная мысль, которую часто упускают: каждый из этих слоёв не заменял предыдущие, а достраивался поверх — поэтому в современном коде можно встретить «старые» идиомы рядом с «новыми». Это не плохо и не хорошо — это особенность живого языка с сорокалетней историей. Типичная ошибка новичков: думать, что «новое = лучшее» и сразу писать в стиле C++23, игнорируя то, что 90% существующего кода написано в стиле C++98/03/11. Учите оба стиля.

Где C++ используется в реальном мире — это важно для мотивации. На C++ написаны браузерные движки (Chromium, Firefox — потому что нужна скорость отрисовки страниц), СУБД (ClickHouse, MongoDB, MySQL — потому что важна скорость обработки миллионов запросов), игровые движки (Unreal Engine, часть Unity — потому что важна скорость рендеринга 60 кадров в секунду), HFT-системы (high-frequency trading — биржевые роботы, где важна каждая микросекунда задержки) и ROS (Robot Operating System — фреймворк для робототехники, где важна работа с железом в реальном времени). Почему именно C++? Скорость + контроль над памятью + богатая стандартная библиотека. Где C++ обычно НЕ используют: веб-бэкенды простой бизнес-логики (там Python/Go удобнее), быстрое прототипирование (там Python/JS), мобильные приложения (там Swift/Kotlin).

Что вы найдёте в этой шпаргалке. Здесь плотно и по делу собраны синтаксис, объектная модель и её память, шаблоны, контейнеры, многопоточность и — главное — подводные камни вроде UB (undefined behavior — неопределённое поведение, когда стандарт не определяет, что произойдёт), slicing (потеря части объекта при копировании по указателю на базу) и инвалидации итераторов (когда указатель внутрь контейнера становится недействительным после изменения контейнера). Зачем подводные камни выделены отдельно: потому что в C++ знать синтаксис — это 30% успеха, остальные 70% — знать, где вас поджидает грабли.

Как пользоваться этой шпаргалкой — практический совет. Держите страницу как справочник: не читайте залпом, а возвращайтесь к нужному разделу. Один и тот же материал, перечитанный трижды с перерывом в неделю, запоминается лучше, чем десять страниц, проглоченных за ночь. Это связано с эффектом «кривой забывания Эббингауза» — мозг забывает 70% новой информации за сутки, если её не повторить. Аналогия: учить C++ за ночь — это как пытаться выучить китайский за ночь перед поездкой в Пекин. Можно выучить «здравствуйте» и «спасибо», но говорить вы не сможете. А вот постепенное повторение — это как регулярные занятия с репетитором: через полгода вы уже сможете поддержать разговор.

Разберём три слова из определения, без которых дальше не обойдёшься. Понимание этих терминов — фундамент, на котором стоит всё остальное.

1. Компилируемый — значит, что текст программы заранее переводится в машинные инструкции отдельной программой-компилятором (g++, clang++, MSVC); в отличие от интерпретируемых языков (Python, JavaScript, Ruby), готовый файл работает быстро и без «переводчика» рядом. Аналогия из жизни: компиляция — это как напечатать рецепт торта в виде готовой книги-инструкции для кондитера (он открыл, прочитал, испёк — всё быстро), а интерпретация — как живой переводчик рядом с иностранным гостем, который переводит каждую фразу на лету (гибко, но медленнее). Первое быстрее в работе, второе гибче в отладке. Именно поэтому C++ обгоняет Python в скорости в десятки и сотни раз, но проигрывает в скорости разработки. Почему это важно понимать: ошибки компиляции (синтаксические) ловятся ДО запуска программы — это плюс. Но цикл «написал → скомпилировал → запустил → увидел результат» длиннее, чем в Python «написал → запустил». Практический совет: чтобы ускорить разработку, используйте режим инкрементальной компиляции (в IDE — это по умолчанию) и кеширование (ccache, ninja). Типичная ошибка: думать, что если код скомпилировался — он работает. Нет! Компилятор ловит только синтаксические ошибки и базовые ошибки типов, но не логические. Скомпилированная программа может падать в рантайме.

2. Ручной контроль ресурсов — память, файлы, блокировки вы освобождаете сами, но в C++ это принято делать не вручную, а через идиому RAII (Resource Acquisition Is Initialization — «захват ресурса есть инициализация», раздел ниже). Простое определение: ресурс — это всё, что программа берёт у системы (память, открытый файл, сетевое соединение, мьютекс) и должна вернуть, когда перестаёт использовать. Аналогия из жизни. Представьте, что ресурс — это арендованный велосипед: на C++ вы сами следите, чтобы вернуть его вовремя, но RAII превращает этот процесс в автоматический — как ключ от замка, который привязан к цепочке: пока вы не положите ключ на место, замок не закроется. RAII в C++ — это магия конструкторов и деструкторов: объект сам себе «владелец» ресурса, и когда объект выходит из области видимости (заканчивается блок {}), деструктор автоматически освобождает ресурс. Почему это важно: в языках с автоматическим сборщиком мусора (Java, C#, Python, Go) программист не думает, когда освободится память. В C++ вы думаете, но с помощью RAII это перестаёт быть страшным — 95% случаев покрываются умными указателями (unique_ptr, shared_ptr). Типичная ошибка новичков: писать new и delete вручную в современном C++. Сейчас это нужно крайне редко — используйте std::vector, std::string, std::unique_ptr. Когда всё-таки нужен ручной контроль: работа с низкоуровневыми системными API, кастомные аллокаторы, embedded-разработка с ограниченной памятью.

3. Статическая типизация — типы проверяются на этапе компиляции, поэтому многие ошибки (опечатки в именах, попытки сложить число со строкой) не доживают до запуска. Простое определение. Тип — это «вид» значения: целое число, дробное число, строка, логическое значение (истина/ложь), пользовательский класс. Статическая типизация значит, что каждая переменная, каждая функция имеют тип, известный ДО запуска программы. Аналогия из жизни: это как проверка чертежа дома до начала стройки: дешевле исправить линию на бумаге, чем сносить готовую стену. Если в чертеже написано «несущая стена из бетона», а вы пытаетесь поставить её на место окна — архитектор (компилятор) скажет «нельзя» ещё до того, как строители (программа) начнут работу. Почему это хорошо: ловит огромный класс ошибок до запуска. Почему это иногда неудобно: нужно заранее продумывать типы, иногда писать длинные декларации. Типичная ловушка: путаница между auto (компилятор сам выводит тип) и слабой типизацией. auto — это всё ещё статическая типизация, просто тип выводит компилятор. Динамическая типизация — это когда тип определяется В МОМЕНТ ВЫПОЛНЕНИЯ (как в Python). Что спрашивают на собеседовании: «В чём разница между статической и динамической типизацией?» и «Какие ошибки ловит статическая типизация, а какие — нет?»

4. Мультипарадигменность — означает, что одну задачу можно решить процедурно (набор функций), объектно (классы и наследование), обобщённо (шаблоны) или функционально (лямбды, алгоритмы) — выбирайте то, что читается проще. Простое определение каждой парадигмы:

• Процедурная — программа как последовательность функций, каждая делает своё (как рецепт: шаг 1, шаг 2, шаг 3).
• Объектная — программа как набор «объектов», у которых есть данные (поля) и действия (методы), они взаимодействуют друг с другом (как оркестр: музыканты-объекты, дирижёр-координатор).
• Обобщённая (generic) — код пишется один раз, но работает с разными типами (шаблоны в C++ — аналог дженериков в Java, но мощнее).
• Функциональная — код строится из маленьких функций, которые не меняют состояние, а возвращают новые значения (лямбды, std::transform, std::accumulate).

На практике это не «или-или», а «и-и-и»: в реальном проекте вы почти всегда смешиваете подходы в зависимости от подзадачи. Аналогия из жизни: как в кулинарии — можно жарить, варить, запекать; хороший повар использует все методы в зависимости от продукта. Типичная ошибка: фанатично следовать одной парадигме («ООП везде!» или «функциональщина везде!»). Хороший C++-программист выбирает инструмент под задачу, а не наоборот. Практический совет: для маленьких утилит — процедурный стиль, для средних систем — ООП + шаблоны, для обработки данных — STL-алгоритмы + лямбды (функциональный стиль).

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

• «Как запомнить» (мнемоника — короткая фраза или образ, помогающий запомнить правило),
• «Частая ловушка» (на что наступают новички и даже опытные),
• «На собеседовании спросят» (формулировки, которые любят интервьюеры),
• «Когда использовать, а когда нет» (практический гайд по выбору).

Важный практический совет по работе с этой шпаргалкой. Не читайте подряд: сначала просмотрите оглавление, а потом открывайте нужный раздел — так информация ложится в контекст задачи и запоминается в три раза лучше, чем при линейном чтении. Это принцип «обучения через необходимость» — мозг лучше запоминает то, что ему нужно прямо сейчас, а не абстрактные знания «на потом». Аналогия: вы не читаете словарь от A до Z — вы ищете конкретное слово, когда оно нужно. Так и здесь.

Какую версию C++ использовать и как запускать примеры. Все примеры рассчитаны на C++20/23 — собирайте их с флагом -std=c++20 (например, g++ -std=c++20 -Wall -Wextra file.cpp -o file), а при сомнениях запускайте под санитайзерами (см. раздел про UB): -fsanitize=address,undefined ловит 90% типичных ошибок ещё до того, как они превратятся в ночной баг в продакшене. Что значат флаги:

• -std=c++20 — включить стандарт C++20 (без этого флага новый синтаксис не скомпилируется);
• -Wall -Wextra — показать все предупреждения (warnings) — их НЕЛЬЗЯ игнорировать, они ловят реальные баги;
• -fsanitize=address — ловит ошибки памяти (use-after-free, утечки, выход за границы массива);
• -fsanitize=undefined — ловит UB (undefined behavior): переполнение знаковых чисел, деление на ноль, сдвиги, выход за границы std::vector через итератор.

Почему санитайзеры — это must-have для обучения. Санитайзер замедляет программу в 2–5 раз и увеличивает расход памяти в 2–3 раза, поэтому в продакшене его не включают. Но для разработки и обучения это лучший друг: вместо того чтобы гадать, почему программа выводит ерунду или падает через час, вы получаете точный отчёт: файл, строка, что случилось. Типичная ошибка новичков: запускать код без санитайзера, получать странное поведение, мучиться часами. Запустите с санитайзером сразу — сэкономите часы.

Техника активного чтения — как извлечь максимум из шпаргалки. Полезный приём: после прочтения раздела закройте шпаргалку и попробуйте воспроизвести ключевой пример по памяти — если получилось, материал усвоен; если нет — перечитайте именно ту часть, где застряли. Это называется «активное воспроизведение» (active recall) и работает в 3–5 раз эффективнее, чем простое перечитывание. Аналогия: перечитать параграф — это как посмотреть, как кто-то другой играет в шахматы. Воспроизвести по памяти — это сыграть самому. Второй путь учит, первый — нет.

Быстрый старт

Что вообще значит «запустить C++-программу». C++ — компилируемый язык: процессор понимает только машинный код (нули и единицы), а не исходники на C++. Поэтому перед запуском специальная программа — компилятор — переводит ваш текст в машинные инструкции и кладёт их в исполняемый файл. Понимание того, как устроен этот процесс, помогает быстро разбираться с ошибками сборки и не бояться CMake. Короткий словарик терминов ниже пригодится сразу: исходник — ваш .cpp, объектный файл — промежуточный .o/obj, библиотека — набор готовых функций (.a/.so/.dll), исполняемый файл — итоговая программа, которую запускает ОС.

Компиляция — что это такое и почему в два этапа. C++ — компилируемый язык: каждый .cpp компилируется независимо в объектный файл (промежуточный бинарник с машинным кодом, но без адресов внешних функций), а линкер соединяет объектные файлы и библиотеки в один исполняемый файл. Представьте себе конвейер сборки мебели: компилятор — это столяр, который из каждой детали (.cpp) делает готовый модуль (.o) со всеми пазами и отверстиями, но без фурнитуры. Линкер — это сборщик, который скрепляет модули болтами, подбирает недостающие детали из каталога (библиотеки) и выдаёт готовый шкаф (исполняемый файл). Такой конвейер позволяет собирать большие проекты по частям и кешировать результат: изменили один .cpp — перекомпилируется только он, остальные модули остаются прежними. Поэтому даже огромные проекты собираются за секунды, а не часы. Ниже — минимальная программа, затем установка компилятора и набор флагов, с которым стоит собирать любой код.

Полезная анатомия ошибки сборки. Если компилятор сообщает «expected ';' before …» или «no matching function for call to …» — проблема в вашем исходнике, линкер тут ни при чём. Если же вы видите «undefined reference to …» или «multiple definition of …» — компиляция прошла успешно, но линкер не может найти нужную функцию (часто забыт .cpp в списке файлов или target_link_libraries для библиотеки), либо нашёл две реализации одного имени в разных единицах трансляции (обычно из-за #include .cpp вместо заголовка). Запомнить просто: первая фаза — синтаксис и типы, вторая фаза — связи между кусками кода. Разница между ними видна по номеру ошибки: error C2065/error: … — компилятор, error LNK…/undefined reference — линкер.

// hello.cpp — первая программа
#include <iostream>   // std::cout — поток вывода на консоль
#include <string>     // std::string — строка, сама управляет своей памятью
#include <vector>     // std::vector — динамический массив

int main() {                                        // точка входа: ОС вызывает именно её
    std::vector<std::string> names{"мир", "C++"};   // вектор из двух строк
    for (const auto& n : names) {                   // range-for: перебираем элементы по ссылке
        std::cout << "Привет, " << n << "!\n";      // << — оператор вывода; "\n" дешевле std::endl
    }
    return 0;                                       // 0 — код успешного завершения
}

Что здесь важно понять с первого взгляда.

• #include — это не «импорт модуля», а тупой текстовый копи-паст: препроцессор буквально вставляет содержимое <iostream> в ваш файл ещё до компиляции. Отсюда и # (директива препроцессора).
• std:: — пространство имён стандартной библиотеки. Префикс нужен, чтобы ваши имена не конфликтовали со стандартными (например, ваша функция count не сломает std::count).
• int main() — единственная функция, которую операционная система вызывает сама при запуске программы. Всё, что вне main, выполняется только если main это вызвал.
• const auto& в цикле — три меры предосторожности сразу: auto угадывает тип, & не копирует строку (избегаем лишних аллокаций), const запрещает случайно её модифицировать.
• std::vector<std::string> — параметризованный (шаблонный) тип: vector — это «коробка», а в <> указывают, что именно в ней лежит. Так же работают std::array, std::list, std::map — одна коробка для разного содержимого.
• // комментарий — однострочный, до конца строки; /* ... */ — многострочный. Многострочные нельзя вкладывать друг в друга — это частый источник «программа съела полфайла».
• \n против std::endl: первое — просто символ перевода строки (быстро), второе дополнительно вызывает flush() — сбрасывает буфер на экран (полезно в отладке, но в горячем цикле — лишние затраты).
• return 0; в конце main — код возврата: 0 означает «всё хорошо». Скрипты, CI и конвейеры читают именно это число, а не вывод на экран.

Установка компилятора одной строкой. На современных Linux (Ubuntu/Debian) обычно хватает sudo apt install build-essential — это сразу GCC, make и стандартные заголовки. На macOS — xcode-select --install (идёт в комплекте с macOS) или brew install llvm для самого свежего Clang. На Windows есть несколько путей: MSYS2/MinGW-w64 — UNIX-подобная среда с GCC прямо в Windows; WSL — настоящий Linux внутри Windows (лучший вариант для кроссплатформенности и совместимости с туториалами); Visual Studio (MSVC) — компилятор от Microsoft, идущий в комплекте с IDE. Для обучения подойдёт любой; для серьёзной работы выбирайте по целевой платформе проекта.

# Linux: sudo apt install build-essential g++  |  macOS: xcode-select --install
# Windows: MSYS2, MinGW-w64 или WSL

g++ hello.cpp -o hello    # собрать
./hello                   # запустить → Привет, мир! / Привет, C++!

# Рабочий набор флагов, который стоит набирать всегда:
g++ -std=c++20 -Wall -Wextra -Wpedantic -O2 -g hello.cpp -o hello

# Проверка на скрытые баги: санитайзеры адреса и неопределённого поведения
g++ -std=c++20 -g -O1 -fsanitize=address,undefined -fno-omit-frame-pointer hello.cpp -o hello_asan
./hello_asan

Почему именно такие флаги, а не другие. -std=c++20 фиксирует стандарт, -Wall -Wextra -Wpedantic включают максимум предупреждений, -g добавляет отладочную информацию, -O2 оптимизирует. Предупреждения компилятора — это найденные баги; в CI добавляйте -Werror, чтобы они останавливали сборку. clang++ совместим по флагам и часто даёт более понятные диагностики; сборка одного и того же кода двумя компиляторами — дешёвый способ поймать UB. Почему -O1 для санитайзеров, а не -O2? Потому что при агрессивной оптимизации компилятор может переставить инструкции так, что санитайзер перестанет точно указывать на виновника. -O1 — компромисс: достаточно оптимизации для реалистичных условий, но не настолько, чтобы замести следы.

g++ против clang++ — практические нюансы. Оба компилятора реализуют один и тот же стандарт, но отличаются в деталях. GCC — исторический стандарт Linux, широкая поддержка платформ, отличная оптимизация под x86, иногда строже к UB. Clang — заметно более быстрая компиляция, лучшие диагностические сообщения (часто с «подсказкой» — did you mean …?), лучшая интеграция с IDE, дружелюбнее к модулям и constexpr. Совет из практики: возьмите за правило периодически собирать проект обеими компиляторами — то, что один пропустит, другой поймает. Полезная тонкость: -fdiagnostics-color=always раскрашивает ошибки в терминале, что сильно упрощает чтение длинных сообщений.

Как запомнить флаги. -std — стандарт (какой C++), -W — warnings (предупреждения), -O — optimization (уровень 0…3), -g — debug info (символы для отладчика), -fsanitize — включить санитайзеры. Мнемоника: «сначала стандарт и предупреждения, потом оптимизация, потом отладка». Полезный мысленный образ: представьте, что вы настраиваете микроскоп — сначала выбираете режим подсветки (-std), потом включаете все индикаторы (-Wall), потом фокусируете картинку (-O), потом включаете рентген (-g/-fsanitize). Каждый шаг добавляет информации, а не заменяет предыдущий.

Мнемоника для уровней оптимизации. -O0 — без оптимизации (для пошаговой отладки, отладочная информация точнее); -O1 — базовая (быстрая сборка, минимальные улучшения); -O2 — рекомендуемая для релиза (большинство безопасных оптимизаций); -O3 — агрессивная (векторизация, развёртка циклов — может ухудшить размер бинарника и не всегда ускоряет код с маленькими «горячими» функциями); -Os — оптимизация по размеру (для embedded и мобильных платформ); -Ofast — опасная: включает -ffast-math, нарушающую строгий IEEE 754 (может сломать численные расчёты и сортировки на граничных значениях).

Частая ловушка. Не собирайте релиз с -O2 и без -Wall: часть ошибок проявляется только при оптимизации (компилятор опирается на отсутствие UB). И наоборот — не измеряйте производительность Debug-сборки: -O0 может замедлить код в десятки раз. Аналогия: замерять скорость машины на ручной буксировке — бессмысленно. И ещё коварный сценарий: код с -O0 «работает», а с -O2 падает — почти наверняка это UB, которое компилятор при оптимизации решил использовать «в свою пользу» (см. правило «as-if»). Санитайзеры ловят это в Debug, но не все.

Когда использовать какой компилятор. Для повседневной работы — тот, что стоит в системе (g++ на Linux, clang++ на macOS). Перед релизом полезно прогнать оба: разные реализации по-разному оптимизируют и находят разные проблемы. Практическое правило: GCC и Clang договорились о стандарте, но расходятся в расширениях и эвристиках. Если код собирается только одним из них — это повод задуматься, не используете ли вы случайно нестандартную возможность. Также MSVC (Visual Studio) имеет свои особенности в обработке шаблонов и constexpr — кросс-компиляция учит писать переносимый код.

Для проектов из нескольких файлов используют CMake:

# CMakeLists.txt — «рецепт» сборки: описывает цель и её зависимости
cmake_minimum_required(VERSION 3.20)   # минимальная версия CMake
project(hello CXX)                     # имя проекта; CXX — используем C++
set(CMAKE_CXX_STANDARD 20)             # стандарт языка
set(CMAKE_CXX_STANDARD_REQUIRED ON)    # запретить откат на более старый стандарт
add_executable(hello hello.cpp)        # цель «hello» собирается из hello.cpp
target_compile_options(hello PRIVATE -Wall -Wextra -Wpedantic)   # флаги именно этой цели

cmake -B build -DCMAKE_BUILD_TYPE=Debug   # конфигурация: сгенерировать файлы сборки в build/
cmake --build build                       # сборка (запускает make/ninja внутри)
./build/hello

Зачем CMake, если g++ и так работает. Для одного-двух файлов CMake избыточен, но в реальном проекте он избавляет от ручной возни: сам находит зависимости, переносим между платформами и IDE и позволяет подключать библиотеки одной строкой (find_package, target_link_libraries). Команды g++ ... из предыдущего блока и CMake — не конкуренты: CMake под капотом вызывает тот же компилятор. Аналогия: g++ напрямую — это ручная готовка по рецепту, а CMake — это кухонный комбайн с тем же рецептом внутри. Для пиццы разница незаметна, для банкета — критична. Полезно знать: CMAKE_BUILD_TYPE влияет на дефолтные флаги — Debug добавит -g, Release добавит -O3 -DNDEBUG. Макрос NDEBUG отключает assert(), поэтому измерения производительности в Release — единственно честные.

Минимум CMake, который нужно понимать с первого дня. Цель (target) — это «что мы делаем»: исполняемый файл (add_executable) или библиотека (add_library). Команды свойств (set, target_*) настраивают, как именно. Переменные в CMake — это строки с подстановкой через ${...}, но современный стиль рекомендует использовать таргетированные команды (target_compile_features, target_link_libraries) — они не «текут» между целями и не зависят от порядка вызовов в файле. Папка build/ — отдельная директория для артефактов: её можно смело удалить, чтобы начать сборку с нуля (rm -rf build/). Если CMake не находит зависимость — добавьте find_package(...) или add_subdirectory(...), чтобы он «увидел» нужный проект.

Что ещё нужно знать про main. Точка входа обязана возвращать int; написание void main() нестандартно и не компилируется частью компиляторов. Код возврата видит оболочка: 0 — успех, ненулевое — ошибка (echo $? в bash). Аргументы командной строки приходят в int main(int argc, char* argv[]): argc — их число, argv[0] — имя программы, argv[argc] — гарантированный nullptr. Дополнение из практики: return 0 в main можно опустить — компилятор подставит его за вас (только в main, ни в какой другой функции). Но писать явно — хорошая привычка: видно, что функция действительно завершается нормально, а не «упала» через исключение или exit(). Коды возврата принято делать осмысленными: 1 — общая ошибка, 2 — неверные аргументы, 127 — «команда не найдена» (по соглашению). Скрипты и CI на это полагаются: if ./myprog; then ... работает именно благодаря коду возврата.

Альтернативные варианты main. Стандарт допускает ровно две формы: int main() и int main(int argc, char* argv[]). Параметры argc и argv — это «как ОС передала вам аргументы»: имена исторические (от argument count и argument vector). Имена параметров менять можно, но argc/argv — настолько устоявшееся соглашение, что отступать от него не стоит (код сразу становится «незнакомым»). Если аргументы не нужны — пишите короткую форму int main(), неиспользованные параметры просто игнорируются.

Частая ловушка. Программа «молча ничего не делает» — проверьте, что вы запускаете именно свежесобранный файл (а не старый из другого каталога), и что компиляция прошла без ошибок: g++ при успехе не печатает ничего, поэтому отсутствие вывода легко принять за успех. Расширенный чек-лист, когда «ничего не работает»:

1. Сработала ли компиляция? echo $? после g++ ... — должно быть 0.
2. Тот ли файл вы запускаете? ls -la hello, pwd, file hello (он вообще исполняемый?).
3. Есть ли вывод в stderr? Иногда ошибки уходят туда, а не в stdout. Запустите ./hello 2>&1 | cat, чтобы увидеть всё.
4. Не упал ли процесс из-за санитайзера? Если собирали с -fsanitize, любое UB печатает подробный отчёт в stderr.
5. Не зависит ли поведение от текущего каталога? Программа могла прочитать файл, которого здесь нет.
6. Нет ли «зомби-процессов» или не занят ли порт, если сервер пишет «address already in use»? Помогает lsof -i :PORT.
7. Не путаете ли вы & (фоновый запуск) и && (логическое «и»)? Одна прописная буква в скрипте меняет всё.
8. Не съел ли буфер ваш вывод? std::cout буферизуется — при крэше (abort, segfault) последние строки не успевают напечататься.

Ещё одна коварная ловушка: забытый буфер вывода. std::cout по умолчанию буферизуется — программа может завершиться штатно, но вы не увидите последних строк (например, при отладке или пайплайне). В обычной программе это не страшно: при нормальном завершении буфер сбрасывается. Но если ваша программа падает (segfault, abort, std::terminate) — буфер не успевает сброситься, и вы не видите, на что упало. Отладочный приём: для подозрительного вывода используйте std::cerr (он небуферизован по умолчанию) либо включите принудительный сброс через std::cout << std::unitbuf (каждый << сразу идёт на экран). То же касается отладочных логов: пишите в std::cerr, чтобы видеть их даже на «падающем» запуске. В продакшене с логированием в файл используют явный flush() либо сторонние библиотеки с очередями — но это уже за пределами «быстрого старта».

Ключевые термины

Простое определение. Это «словарь идей» современного C++. Не синтаксис, а принципы: как код собирается в программу, как живут объекты, как компилятор принимает решения. Если вы понимаете эти идеи, чужой код и умные книжки перестают казаться магией. Термины ниже встречаются буквально в каждой главе дальше — без них не разобрать ни std::vector, ни шаблоны, ни правила линковки.

Дальше в тексте часто встречаются эти слова. Не старайтесь выучить их сразу — вернитесь к таблице, когда термин попадётся в коде. Третий столбец даёт бытовую аналогию: она помогает ухватить смысл, даже если формальное определение забылось. В среднем столбце помимо формального определения есть короткая подсказка «на что обратить внимание» — это та деталь, которая чаще всего всплывает на практике или на собеседовании.

Как запомнить главное. Термины делятся на три группы, и эта группировка — половина успеха:

1. Про сборку программы — TU, ODR, ADL. Эти слова встретятся, когда речь пойдёт про заголовки, линковку и поиск функций. Если вы понимаете, как из .cpp получается исполняемый файл, эта тройка перестаёт быть магией. Конкретнее: TU объясняет, почему каждый .cpp компилируется независимо; ODR — почему нельзя определить функцию в .h без inline; ADL — почему std::swap(a, b) находит «правильную» перегрузку без std::-префикса.
2. Про память и владение ресурсами — RAII, move, SSO, slicing, инвалидация. Здесь живут главные практические вопросы: «кто освобождает память?», «почему итератор сломался?», «почему после push_back всё упало?». Эти термины напрямую связаны: RAII — общий принцип, move — способ передачи ресурсов без копий, SSO — оптимизация для частного случая, slicing и инвалидация — типичные ошибки, которые из них вытекают.
3. Про компилятор и шаблоны — UB, SFINAE, concepts, vtable, NRVO, POD/trivial. Это «внутренняя кухня»: как компилятор принимает решения, почему код быстрый или медленный, откуда берутся неожиданные сообщения об ошибках. UB и vtable/NRVO — про оптимизации и их границы; SFINAE/concepts — про отбор шаблонов, от «страшного» старого к новому чистому синтаксису.

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

На собеседовании спросят. Почти гарантированно попросят объяснить RAII, UB и slicing своими словами — это маркеры того, что человек писал на современном C++, а не только читал учебник. Почти так же часто залезают в соседнюю зону и спрашивают:

• разницу между move и копированием (и что значит «valid but unspecified state»);
• почему инвалидация итераторов — причина падений в продакшене и как с этим жить (reserve, list вместо vector, пересоздание итератора);
• что такое vtable и почему класс с виртуальными методами становится «не POD» и тяжелее по памяти;
• зачем нужны concepts и чем они лучше SFINAE (читаемость ошибок, явные требования).

Как отвечать, чтобы не «провалиться»: не начинайте с формального определения из стандарта — собеседователь это и так знает. Лучше сразу привести короткий сценарий из жизни: «RAII — это когда я открыл файл в конструкторе объекта, и теперь даже если из функции вылетело исключение, файл закроется автоматически в деструкторе, и мне не надо писать try/catch вокруг каждого вызова». На конкретном примере видно, что вы не зубрили, а понимаете. Если спрашивают про UB — обязательно упомяните, что компилятор может оптимизировать код, считая, что UB не случится, и привести конкретный пример (if (p) *p после *p = 0, исчезающая «защитная» проверка). Если спрашивают про slicing — упомяните про std::vector<std::unique_ptr<Base>> как канонический способ хранить полиморфные объекты и про виртуальный clone() для глубокого копирования.

Хороший ответ — это не пересказ определения, а короткая история: «я встретил это, когда у меня в программе случилось вот это, и я решил это так». Умеете рассказать такую историю — собеседование прошло.

Модель компиляции и линковки

Что такое компиляция в C++? Это не один процесс, а конвейер — последовательность из четырёх независимых программ, каждая из которых берёт результат работы предыдущей и превращает его во что-то более «машинно-ориентированное». Понимание этого конвейера — ключ к пониманию большинства ошибок, с которыми сталкивается новичок, потому что на каждом этапе свои правила и свои сообщения об ошибках. Если хотите совсем коротко: компиляция в широком смысле — это всё, что превращает ваш .cpp в исполняемый файл; в узком смысле (когда говорят «фаза компиляции») — это только этапы 1–3 до получения объектного файла.

Препроцессор — самый первый этап, и он работает только с текстом: ещё не понимает ни типов, ни синтаксиса C++. Его задача — подставить содержимое #include (буквально скопировать текст из указанного файла) и раскрыть #define-макросы (заменить каждое вхождение имени на его тело). Представьте себе редактора, который по инструкции «везде, где написано X, подставь Y», правит книгу до того, как её начнут читать программисты. Именно поэтому препроцессор не умеет проверять типы — он оперирует буквами, а не смыслом. Любая синтаксическая ошибка, попавшая внутрь макроса, обнаружится только на следующем этапе, и сообщение об ошибке будет ссылаться уже на раскрытый текст — поэтому иногда трейс указывает в странное место.

Компилятор — следующий этап. Он берёт уже «раскрытый» текст и переводит его в ассемблер — символьный машинный код конкретного процессора (x86, ARM и т.п.). Здесь уже проверяются типы, синтаксис, семантика C++. На выходе — файл, понятный только ассемблеру, но не процессору напрямую. Именно компилятор решает, какие конструкции языка корректны, какие перегрузки функций вызвать, как сопоставить шаблон с аргументами. Кстати, «компилятор» в широком смысле часто называют всю цепочку g++, а в узком — только средний этап; имейте это в виду, читая документацию.

Ассемблер превращает этот ассемблерный текст в объектный код (.o или .obj): это уже настоящие машинные инструкции, но в файле есть «дыры» — места, где должны быть адреса функций и переменных из других файлов, но их пока нет. Поэтому к объектному файлу прилагается таблица символов — список имён, которые он объявляет и которые хочет получить снаружи. Объектный файл — это почти готовый кусок программы, но с пометками «здесь будет адрес функции X, подставите потом».

Линкер — финальный сборщик. Он берёт все объектные файлы и нужные библиотеки, сопоставляет имена из таблиц символов, подставляет реальные адреса и склеивает всё в один исполняемый файл или библиотеку. Если какого-то имени не нашлось — вы получаете ошибку именно на этом этапе. Линкер ничего не знает о C++ как о языке: для него есть только имена символов и их таблицы. Поэтому многие ошибки ODR (множественное определение) звучат «сухо»: линкер просто видит два символа с одним именем.

Понимание этих этапов объясняет две самые частые ошибки новичка: undefined reference приходит от линкера (он не нашёл нужную функцию или переменную), а implicit declaration — от компилятора (он не нашёл объявление функции и решил использовать устаревшее правило языка). Запомните этот «язык ошибок»: видите reference — это линкер; видите declaration / type / expected — это компилятор; видите что-то про #include не найден — это препроцессор.

g++ -E main.cpp -o main.i    # 1. препроцессор: раскрыл #include и #define
g++ -S main.i -o main.s      # 2. компилятор: C++ → ассемблер
g++ -c main.s -o main.o      # 3. ассемблер: ассемблер → объектный код
g++ main.o -o main           # 4. линкер: объектный код + библиотеки → бинарник

Как запомнить флаг каждого этапа. -E (expand/preprocess) — только препроцессинг; -S (source → assembly) — до ассемблера; -c (compile only) — до объектного файла; без флага — собрать и слинковать всё сразу. Порядок букв подсказывает «глубину» остановки: E → S → c → готовый файл. Полезный трюк: если программа падает с загадочной ошибкой, прогоните g++ -E и посмотрите, во что раскрылись макросы — иногда это сразу показывает источник проблемы. А g++ -c file.cpp — самый быстрый способ проверить, компилируется ли отдельный файл вообще (без линковки). Ещё одна мелочь: на практике обычно выполняют g++ -c file.cpp -o file.o одной командой, без промежуточных .i и .s; разбиение по этапам нужно либо для отладки, либо для понимания, что именно происходит.

Что такое «объявление» и «определение» и почему их путают. Это разные вещи, и компилятор/линкер относятся к ним по-разному. Объявление (declaration) — это обещание: «где-то есть сущность с таким именем и такой сигнатурой, доверьте мне». Определение (definition) — это воплощение: «вот конкретное тело функции / конкретное значение переменной». Одно и то же имя может быть объявлено сколько угодно раз в разных местах, но определено — строго один раз (это правило ODR, One Definition Rule, о нём ниже). Простая проверка для себя: если в строке есть фигурные скобки { ... } с телом функции — это определение; если только ; после сигнатуры — это объявление. Для переменных: extern int x; — объявление, int x = 5; (или int x; на уровне namespace) — определение.

На собеседовании спросят. «Почему ошибка undefined reference to 'foo' появляется не при компиляции, а при линковке?» Ответ: на этапе компиляции достаточно объявления (прототипа) — компилятор лишь проверяет типы и оставляет адрес незаполненным; тело функции ищет уже линкер, и если не находит — падает. Дополнение для полноты: если вы забыли объявление, а тело функции есть, вы получите implicit declaration от компилятора (в современных версиях GCC/Clang — warning, а не error, но с -Werror это станет ошибкой). Так что две похожие ошибки про одно и то же имя приходят от разных этапов конвейера — и поэтому важно понимать, кто именно жалуется. Следствие отсюда: правильно настроенный проект должен включать -Wall -Wextra -Werror — тогда «молчаливая» ошибка прототипа превратится в явную.

Правило разделения: объявления — в заголовок .hpp, определения — в .cpp. Заголовок подключается в каждый .cpp, который использует объявленные сущности. Зачем так? Компилятор должен знать сигнатуру (имя, типы параметров, тип возврата), чтобы проверить вызов, но тело функции нужно увидеть лишь один раз во всей программе — иначе символ продублируется и линкер выдаст ошибку множественного определения. Заголовок — это «оглавление» модуля, а .cpp — его «текст». Если провести аналогию из жизни: представьте книгу. Заголовок .hpp — это её оглавление с краткими описаниями глав (название функции, какие аргументы принимает, что возвращает). Сами главы лежат отдельно — в .cpp-файлах. Читатель (другой .cpp) сначала смотрит в оглавление, понимает, что за функция перед ним, а потом библиотекарь (линкер) находит для него полный текст нужной главы. Если бы каждая глава дублировалась в каждой книге — был бы хаос; то же самое произойдёт и с кодом.

Практический совет. Заголовочный файл должен быть самодостаточным — если его подключить в пустой .cpp, тот должен скомпилироваться без ошибок. Для этого подключайте в заголовке всё, что в нём используется (другие заголовки, стандартные библиотеки), а не полагайтесь на то, что пользователь «уже подключил что нужно». Это правило называется «include what you use» (IWYU) и экономит часы отладки. Симптом проблемы: проект собирается на вашей машине, но падает у коллеги, который подключает заголовок в другом порядке — классический признак «грязных» зависимостей в заголовке.

// point.hpp — заголовок с объявлениями
#pragma once                 // нестандартно, но поддерживается всеми компиляторами
#include <cstdlib>           // std::abs

struct Point {
    int x = 0;
    int y = 0;
    int sum() const;         // объявление метода
};

inline int manhattan(const Point& a, const Point& b) {   // inline: определение в заголовке разрешено
    return std::abs(a.x - b.x) + std::abs(a.y - b.y);
}

extern int global_counter;   // объявление переменной: определение будет в одном .cpp

// point.cpp — определения
#include "point.hpp"

int Point::sum() const { return x + y; }   // определение метода

int global_counter = 0;                    // ровно одно определение на программу

О роли inline и extern. В примере выше функция manhattan помечена inline — это разрешает хранить её определение прямо в заголовке. Почему это работает без нарушения ODR? Слово inline подсказывает линкеру: «таких определений может быть несколько в разных TU, и они обязаны быть одинаковыми — выбери любое или объедини». Это легальный способ держать маленькие вспомогательные функции в заголовке, не заставляя пользователя подключать отдельный .cpp. Заметьте: исторически inline появилось как подсказка компилятору «вставь тело в место вызова для скорости», но в современном C++ его главная роль — именно «разрешение множественного определения в разных TU». Оптимизация теперь побочный эффект, а основная гарантия — линковочная.

А extern int global_counter; — это чистое объявление без значения. Слово extern означает: «переменная определена где-то в другом месте программы». Парное ему объявление без extern, но со значением — int global_counter = 0; в .cpp — становится определением. Если в программе окажется два определения одной и той же глобальной переменной, линкер выдаст ошибку множественного определения (multiple definition). Маленькая ловушка: extern int global_counter = 0; — это и объявление, и определение одновременно (extern + инициализатор), и оно тоже должно быть единственным.

Ключевые правила ODR:

• Функция или глобальная переменная определяется один раз во всей программе (кроме inline).
• inline-функции и шаблоны разрешено определять в заголовке — линкер сольёт их.
• Функции-члены, определённые внутри тела класса, неявно inline.
• Классы, enum, шаблоны, constexpr-сущности можно определять в нескольких TU, если определения идентичны.
• Нарушение ODR — это UB, а не ошибка компиляции: линкер молча выберет одно определение.

Почему это важно. Если одно и то же имя определено по-разному в двух .cpp, каждый файл компилируется в неведении о другом — ошибки нет. А линкер увидит два символа с одинаковым именем и просто возьмёт один. Получится, что разные части программы работают с разными версиями функции: в a.cpp size() вернёт 10, а в b.cpp — 20. Отлаживать такое крайне тяжело, поэтому ODR и называют «правилом, которое нельзя нарушать молча».

Дополнительная аналогия. ODR — это как паспортный контроль в аэропорту: имя у двух людей может совпадать, но паспорт (определение) должен быть один и тот же — уникальный. Если два человека покажут разные паспорта на одно имя, никто не сорвёт тревогу при посадке (компиляция пройдёт), но в городе назначения кто-то получит чужой багаж (линкер выберет наугад), и последствия будут непредсказуемыми. Именно поэтому хорошие компиляторы и линкеры включают предупреждения о множественных определениях, а в строгих режимах (-flto, -fno-common) делают это ошибкой. Совет: добавляйте -fno-common в CFLAGS для проектов на C и будьте внимательны с C++ — там похожие ситуации ловятся иначе.

// Ловушка: разные определения в разных TU → UB, линкер не заметит
// a.cpp:  int size() { return 10; }
// b.cpp:  int size() { return 20; }   // нарушение ODR, поведение не определено

// Правильно: static или анонимное пространство имён делает связь внутренней
namespace {
    int internal_helper() { return 42; }   // видна только в этом TU
}

Что здесь происходит и зачем это нужно. В первом блоке показана классическая ловушка: в двух разных единицах трансляции (translation unit, TU — это .cpp после препроцессора) определена функция с одинаковым именем, но разным телом. Каждый .cpp компилируется отдельно и ничего не знает о «собрате» — компилятор доволен. Линкер тоже формально не ругается (если это не extern-функция с внешней связью и нет -fno-common), он берёт одно из определений — какое именно, зависит от порядка линковки и фазы луны. В итоге в одной части программы size() возвращает 10, в другой — 20. Классический «плавающий» баг. Запомните: TU — это не .cpp, а то, что получилось после препроцессора; именно поэтому один и тот же .cpp с разными -D даёт разные TU и потенциально разное поведение.

Второй блок — решение. Анонимное пространство имён (unnamed namespace) — это идиоматический способ сказать: «всё, что внутри, имеет внутреннюю связь (internal linkage), то есть видно только внутри этого TU». Компилятор для каждого TU генерирует уникальное имя (например, _ZN12_GLOBAL__N_115internal_helperEv вместо просто internal_helper), поэтому коллизий между TU не возникает в принципе. Это современная замена ключевому слову static для функций и переменных на уровне файла: static int helper() { ... } работает так же, но namespace { ... } удобнее, когда нужно спрятать сразу несколько сущностей или типы. К тому же анонимный namespace работает и для пользовательских типов (struct, class), а static — нет.

Подсказка на практике. Если вы пишете вспомогательную функцию, которая нужна только в одном .cpp, — оборачивайте её в анонимное пространство имён, а не объявляйте static. Это масштабируется на любое количество локальных имён, не загрязняет глобальное пространство и читается единообразно с другими современными практиками C++. Внутри .cpp без разницы, что выбрать, — но в заголовочном файле static для типов и переменных нарушит ODR (получите копию в каждом TU), а анонимный namespace в заголовке — вообще частая ошибка новичков, потому что каждая TU получит свою «анонимную» сущность.

Когда использовать, а когда нет. Заголовок с объявлениями (.hpp) — всегда; определение в заголовке — только если оно inline, шаблон или constexpr. Вспомогательную функцию, нужную одному модулю, прячьте в static или анонимное пространство имён, чтобы не «засорять» глобальные символы и не ловить конфликты имён с чужими библиотеками. Антипример: определять обычную функцию в .hpp без inline — гарантированная ошибка линковки при наличии двух .cpp, подключивших этот заголовок.

Простая аналогия. Представьте ресторан. Объявление (declaration) — это пункт в меню: «У нас есть борщ». Определение (definition) — это рецепт на кухне: как борщ реально варится. Меню видно всем посетителям (заголовок), а рецепт — внутренняя кухня (.cpp). Если положить рецепт борща в общее меню, его увидят все рестораны сети — и смогут «готовить по нему», но тогда борщ начнёт готовиться в каждой кухне отдельно (копия кода), что неэффективно и опасно. Поэтому рецепты шаблонов и inline функций приходится класть в «общее меню» — иначе кухня просто не сможет их приготовить.

Что кладём в .hpp, а что — в .cpp (шпаргалка):

• В .hpp (заголовок): объявления функций, объявления классов/структур, inline функции, шаблоны, constexpr/consteval функции, макросы, enum class.
• В .cpp (исходник): определения обычных функций, определения методов класса, определения статических полей класса, реализации шаблонов при явном инстанцировании.
• Анонимный namespace или static в .cpp: «приватные» функции, которые нужны только этому файлу — они не видны другим TU, поэтому конфликтов имён не будет.

Шаблоны нельзя вынести в .cpp без явного инстанцирования: компилятор должен видеть тело в момент вызова. Поэтому шаблоны живут в заголовках (или в .ipp, подключаемом из заголовка). Почему так. Шаблон — не код, а «инструкция по изготовлению кода»: конкретная функция рождается только тогда, когда известен тип-параметр. Если тело спрятано в другом .cpp, компилятор при вызове не сможет изготовить версию для вашего типа — он просто не видит текста. Из этого же правила следует типичная боль: время компиляции проектов с «жирными» шаблонами в заголовках может взлетать, потому что каждый TU заново парсит и инстанцирует всё заново — отсюда практика forward declaration и pimpl.

Аналогия из жизни. Шаблон — это форма для печенья (звёздочка, ёлочка, сердечко). Сама форма — ещё не печенье. Чтобы получить печенье, нужна форма прямо сейчас, когда вы замешиваете тесто. Если форма лежит в соседней кухне, а у вас только тесто — печенья не получится. Точно так же: при вызове myFunc<int>(x) компилятор должен «испечь» версию для int, и для этого тело шаблона должно лежать в той же единице трансляции. В .ipp (include payload) — это как держать формы в общей кладовой рядом с тестом: включаешь заголовок — и форма автоматически оказывается под рукой.

Практическая подсказка. Если шаблон очень большой и засорять заголовок не хочется, используйте паттерн «заголовок + .ipp»: в .hpp остаются только объявления шаблонных функций, а в .ipp — их тела. В конце .hpp пишут #include "myclass.ipp", и потребитель ничего не замечает. Либо явно инстанцируйте нужные типы в .cpp (template class MyClass<int>;), но тогда использовать шаблон с другими типами будет нельзя. Третий путь — extern template: объявить инстанцирование «где-то ещё» и инстанцировать только в одной TU, ускоряя сборку остальных.

# Полезные флаги линковки
g++ main.o -o app -L/usr/local/lib -lmylib -lpthread   # порядок -l ВАЖЕН: библиотека после объекта
g++ -c file.cpp -Ifinclude -DDEBUG=1                   # -I каталог заголовков, -D макрос

Расшифровка флагов. Это флаги для gcc/g++/clang/clang++ (нижележащему линкеру ld они передаются через -Wl,...). Библиотека — это заранее скомпилированный файл с готовыми функциями/классами, к которому мы «пристыковываем» свой проект; без библиотек пришлось бы каждый раз писать всё с нуля — даже реализацию printf. -L путь — добавь каталог, где искать библиотеки (аналог переменной PATH в ОС, только для .so/.a); полезно, если библиотека лежит не в стандартных местах вроде /usr/lib, /usr/local/lib. -lимя — подключи библиотеку libимя.so или libимя.a (префикс lib и суффикс .so/.a добавляются автоматически — это соглашение об именовании в Unix-системах: линкер буквально ищет файлы вида lib<имя>.so в путях поиска). -I путь — добавь каталог заголовков для #include "..." и #include <...> (пути из -I просматриваются раньше системных, поэтому можно случайно перекрыть стандартный заголовок — соблюдайте осторожность). -DМАКРОС=значение — определи макрос прямо из командной строки, как если бы в начале файла стояло #define МАКРОС значение; удобно для условной компиляции: -DDEBUG (включить отладочный код) или -DNDEBUG (отключить assert() в release-сборке).

Частая ловушка — порядок -l. Линкер обрабатывает файлы строго слева направо и на каждом шаге пытается закрыть уже встреченные нерешённые символы (unresolved symbols). Нерешённый символ — это имя функции или переменной, которая объявлена (компилятор поверил, что она где-то есть), но тело/определение которой линкер ещё не нашёл в текущей сборке. Из статической библиотеки .a линкер берёт только тот объектный файл, в котором есть нужный символ, — он не сканирует всю библиотеку «на всякий случай» (это экономит время при больших .a). Поэтому, если библиотека стоит слева от объектного файла, который её использует, линкер ещё не знает, что она понадобится, и выдаст undefined reference. Правило: сначала объектные файлы, потом библиотеки, а при взаимных зависимостях перечислять нужную библиотеку дважды или обернуть группу в -Wl,--start-group ... -Wl,--end-group.

Аналогия. Представьте, что вы собираете рюкзак в поход. Объектные файлы — это список «что мне нужно взять» (фляжка, спальник, тушёнка). Библиотеки — это магазины, где это можно купить. Если вы сначала заходите в магазин, а потом составляете список — продавец не знает, что именно вам нужно, и ничего не продаст. Но если сначала составить список, а потом идти по магазинам — продавец видит: «фляжку? вот, пожалуйста». Линкер работает ровно так же: он «закрывает» только те символы, которые уже увидел в объектных файлах, и не сканирует библиотеки «на всякий случай». Бонус для общего развития: с динамическими .so действует та же логика, но «наказание» мягче — код не найдётся уже при запуске программы (сообщение error while loading shared libraries), а не на этапе сборки; именно поэтому порядок -l для .so чуть менее критичен, но всё равно важен.

Практические правила порядка:

1. Сначала все .o (или .cpp при прямой сборке), которые используют внешние библиотеки.
2. Потом библиотеки, которые предоставляют эти символы.
3. Если библиотека A зависит от B, а B — от A (цикл): укажите A дважды: -lA -lB -lA.
4. Системные библиотеки (math, pthread, stdc++) — обычно в самом конце.
5. С GCC/Clang можно добавить флаг -Wl,--start-group ... -Wl,--end-group для автоматического разрешения циклов, но это замедляет линковку.

Дополнительные нюансы, которые часто упускают:

• При компиляции напрямую вида g++ main.cpp -lfoo порядок обычно менее критичен: современные драйверы gcc/clang сами дописывают нужные системные библиотеки в конец команды (-lstdc++, -lm, -lgcc_s, -lc). Проблема всплывает при ручной линковке через ld или в крупных проектах, где порядок задаётся вручную.
• Статические библиотеки (.a) подчиняются правилу порядка строго. Динамические (.so) — мягче, но всё равно требуют, чтобы хотя бы один объектный файл «попросил» символ.
• Каталоги из -L просматриваются до стандартных, поэтому туда удобно класть свою версию библиотеки (-L./vendor -lfoo), не затрагивая системную.
• Библиотеки, которые сами зависят от других (например, libpng → libz), внутри себя уже «знают» свой порядок; вам нужно лишь подключить внешнюю.

Диагностика: кто виноват — компилятор или линкер.

Как читать таблицу. Колонка «Этап» сразу подсказывает, куда копать:

• Компилятор — проблема в одном файле: забыли #include, опечатка, нарушение типов, синтаксическая ошибка. Чиним в исходниках (.cpp/.hpp).
• Линкер — проблема в сборке целиком: файлы не скомпилированы, не добавлены в команду, библиотека не подключена или не найдена. Чиним в системе сборки (CMakeLists.txt, Makefile, meson, команды сборки).

Простой способ отличить «на глаз»: компилятор оперирует одним файлом (одной translation unit — результатом обработки .cpp со всеми его #include после препроцессора) и не знает, что есть в других .cpp. Линкер уже видит все объектные файлы разом и жалуется на «стыки» между ними и библиотеками. Поэтому сообщения компилятора ссылаются на строку и колонку конкретного файла, а сообщения линкера — сразу на несколько объектных файлов и сущностей.

Если ошибка повторяется после исправления — проверьте, не осталось ли старых бинарных файлов: сделайте make clean или удалите кэш сборки (например, папку build/). Часто линкер «не видит» исправлений именно потому, что использует устаревший .o — компилятор решил, что исходник не менялся (по дате и хешу), и не пересобрал его. То же бывает с прекомпилированными заголовками (.pch) и кэшем ccache — их тоже стоит сбросить. Ещё одна частая ловушка: правки в .hpp, которые включает много .cpp, — если зависимости не отслеживаются автоматически, пересоберите проект целиком.

Как запомнить. Ошибки компиляции — про текст и типы внутри одной translation unit (одного .cpp со всеми его #include). Ошибки линковки — про символы и связи между разными .cpp и библиотеками. Практическое правило: если в сообщении встречается имя незнакомой вам функции — скорее всего, вы забыли #include; если имя знакомое (вы точно его определяли сами) — забыли добавить файл или библиотеку в сборку, либо возникла циклическая зависимость между библиотеками.

Мнемоника для быстрой диагностики:

1. Видите слово declared / not declared / no type → компилятор, копаем в .cpp/.hpp (заголовки, области видимости, using, шаблоны).
2. Видите слово undefined reference / multiple definition / cannot find → линкер, копаем в команде сборки и CMakeLists/ Makefile.
3. Видите expected ‘;’ / expected ‘}’ / no matching function → компилятор, синтаксис или несоответствие типов (аргументы перегруженной функции, неявные приведения).
4. Видите relocation / undefined symbol в ассемблерных сообщениях → линкер или проблема с ABI: смешивание C и C++ без extern "C", разная видимость символов (static vs extern), разные calling conventions.

Подсказка: если сообщение очень длинное и в нём упоминается «.o», фраза undefined reference или in function, и за ней часто идёт стрелка вроде main.cpp:12: — это почти наверняка этап линковки. У компилятора формат короче: file:line:column: описание.

Золотое правило. Компилятор превращает каждый .cpp в отдельный .o независимо от других файлов — он вообще «не знает» про остальные .cpp в проекте. Линкер склеивает все .o и библиотеки в один бинарник. Если ошибка исчезает при компиляции одного файла, но появляется при сборке проекта — это 100% проблема линкера. Обратное тоже верно: если ошибка уже есть при g++ -c file.cpp (компиляция без линковки), то это 100% компилятор. Полезно проверять на двух уровнях — это самый быстрый способ локализовать неисправность без догадок.

Типы, инициализация, auto/decltype

Фундаментальные (встроенные) типы — это базовые типы данных, которые язык предоставляет «из коробки»: целые числа, вещественные числа, символы, логический тип и void. В C++ их набор почти совпадает с C, но, в отличие от Java или Python, размер фундаментального типа не фиксирован стандартом — он зависит от платформы. Это частая ловушка для новичков: код, который работает на 64-битном Linux, может вести себя иначе на Windows или на микроконтроллере.

Простое определение для новичка. Тип данных — это контракт между программистом и компилятором: сколько памяти выделить, какие значения допустимы и какие операции разрешены. Фундаментальный тип — это тип, который компилятор понимает без подключения сторонних библиотек (в отличие от, скажем, std::string или std::vector).

Стандарт гарантирует лишь минимальные диапазоны: int — не меньше 16 бит, long long — не меньше 64. А конкретные размеры задаёт так называемая модель данных ОС и компилятора:

• на 64-битном Linux/macOS это LP64: long и указатель — 8 байт, int — 4;
• на Windows — LLP64: long остаётся 4 байтами, 8 байт только у long long и указателя;
• на 32-битных платформах всё ещё меньше: указатель 4 байта, а long может быть как 4, так и 8 байт.

Аналогия из жизни. Представьте, что вы заказываете «стакан кофе». В Италии это ~30 мл, в России ~250 мл. Слово одно, а размер разный. Так же и с int — «стакан» условный, а реальный объём зависит от «страны» (платформы). Поэтому правило такое: как только размер критичен (бинарные форматы файлов, сетевые протоколы, работа с байтами, сериализация), берите типы фиксированной ширины из заголовка <cstdint> — int32_t, uint64_t и т. п. Их ширина задана в битах буквально в названии.

Ещё одна аналогия. Думайте о фундаментальных типах как о ящиках на складе без этикеток: вы знаете, что там что-то лежит, но точный размер узнаёте, только приложив линейку (sizeof). А int32_t — это ящик с наклейкой «гарантированно 32 бита»: открывать и мерить не нужно.

#include <cstdint>
#include <iostream>

int main() {
    std::int8_t  a = -100;      // ровно 8 бит
    std::uint8_t b = 255;
    std::int64_t big = 9'000'000'000'000'000'000LL;   // разделитель разрядов (C++14)
    std::size_t  n = 42;        // беззнаковый тип для размеров и индексов

    std::cout << sizeof(a) << ' ' << sizeof(b) << ' '
              << sizeof(std::size_t) << ' ' << big << '\n';
    // char=1, int обычно 4, long=8 на Linux LP64 и 4 на Windows LLP64
    return 0;
}

Что это значит на практике.

• «Типичный размер» в таблице — это про современную 64-битную платформу; не закладывайтесь на эти числа в логике программы. Когда нужна точная ширина (сериализация, бинарные протоколы, заголовки файлов) — берите intN_t/uintN_t.
• std::size_t беззнаковый, поэтому цикл for (int i = 0; i < v.size(); ++i) выдаст предупреждение о сравнении знакового с беззнаковым и потенциальный баг (например, при i >= 0 после декремента). Безопаснее: for (std::size_t i = 0; i < v.size(); ++i) либо range-based for. Также помните: size_t не может быть отрицательным, поэтому s.size() - 1 при пустом контейнере превращается в огромное положительное число, а не в -1.
• std::ptrdiff_t нужен там, где разность указателей может быть отрицательной (например, p2 - p1 или std::distance). Его ширина совпадает с шириной указателя, что гарантирует, что результат поместится.
• std::string пользуется SSO (Small String Optimization): короткие строки (обычно до ~15 символов) хранятся прямо внутри объекта, без обращения к new/delete. Поэтому sizeof(std::string) всегда один и тот же, независимо от длины хранимой строки.

Типичная ошибка новичка. Написать for (int i = s.size() - 1; i >= 0; --i) для пустой строки: s.size() — это size_t, вычитание единицы даёт 18446744073709551615 на 64-битной платформе, цикл крутится очень долго, программа «зависает». Способ защиты — взять знаковый тип (int, long long) или итерироваться от начала, или проверять empty() заранее.

Как запомнить. size_t — от слова size (размер), ptrdiff_t — от pointer difference (разность указателей). Оба логически связаны с указателями, поэтому их ширина совпадает с шириной адреса на платформе. Если нужно «для индекса» — size_t, если нужно «для смещения, которое может быть минусовым» — ptrdiff_t.

Литералы: суффиксы и основания. Литерал — это фиксированное значение, записанное прямо в коде (например, 42, 3.14, "text"). Тип литерала можно уточнить суффиксом, а систему счисления — префиксом. Это важно, потому что 1 << 31 при int — UB (undefined behavior, неопределённое поведение: сдвиг знакового числа в знаковый бит), а 1u << 31 — корректно, так как операнд беззнаковый.

42          // int
42u         // unsigned int
42L         // long
42LL        // long long
3.14        // double
3.14f       // float
3.14L       // long double
'a'         // char
"text"      // const char[5]
0b1010      // двоичный литерал (C++14)
0x1F        // шестнадцатеричный
0o17        // восьмеричный (C++14)
1'000'000   // разделитель разрядов (C++14)

Почему это важно.

• 0xFFFFFFFF не означает автоматически unsigned: тип литерала выбирается по правилам «первый подходящий». На платформе, где int 32-битный, 0xFFFFFFFF — это int со значением -1, а не unsigned 4294967295. Отсюда неожиданные переполнения, отрицательные значения после приведения и баги в знаковых сравнениях.
• Для битовых операций, масок и значений, которые должны быть беззнаковыми, всегда пишите суффикс u/ull (0xFFu, 0xFFFFFFFFull, 1ull << 33). Это делает намерение явным и убирает целый класс ошибок.
• Разделитель разрядов ' (апостроф) — чисто визуальная штука: компилятор его игнорирует, поэтому 1'000'000 и 1000000 — одно и то же число. Используйте его для читаемости больших литералов (денежные суммы, ID, байтовые смещения).
• Суффиксы f/L для вещественных меняют не только размер, но и точность: 3.14f — это float (~7 цифр), а 3.14L — long double (на x86 обычно 80-битный extended precision). Если вы пишете научные расчёты и важна точность — явно выбирайте long double.

Типичная ошибка. Сравнение -1 == 0xFFFFFFFFu и удивление, что результат false: -1 — это int, а 0xFFFFFFFFu — unsigned, и после «расширения» -1 превращается в огромное положительное число 0xFFFFFFFF, но как unsigned оно не равно 0xFFFFFFFFu (да, не равно самому себе по модулю сравнения в unsigned-арифметике здесь нюанс с знаковым представлением; проще — пишите суффикс и не сравнивайте знаковое с беззнаковым).

Что такое auto и decltype (короткое определение).

• auto — спецификатор типа, который просит компилятор самому вывести тип переменной по инициализатору справа от =. По сути это та же логика вывода типов, что и в шаблонах функций: template <class T> void f(T x).
• decltype(expr) — оператор, который возвращает точный тип выражения expr так, как оно объявлено, не вычисляя само выражение. Используется в обобщённом коде и шаблонах, когда нужно «спросить тип» без инициализации переменной этим значением.

auto выводит тип из инициализатора, но отбрасывает ссылки и const: auto a = ref; сделает копию, а const-ность потеряется. decltype же сохраняет и ссылку, и const — это принципиальная разница.

Аналогия из жизни. auto — как «сфотографировать человека»: на снимке не видно, что оригинал подписан на журнал; decltype — как «привести человека лично», со всеми его свойствами. Другой пример: auto — это ксерокопия документа (без печати и подписи), а decltype — оригинал со всеми атрибутами.

Почему так работает (немного теории). Правила вывода auto исторически совпадают с правилами вывода параметров шаблона по значению: в f(T) аргумент всегда копируется, поэтому верхний уровень const и ссылочность «снимаются». decltype появился позже и намеренно сохраняет всю «типовую шелуху» — именно для метапрограммирования и шаблонов, где важно знать, был ли аргумент ссылкой или const.

decltype(auto) (C++14). Это гибрид: пишете decltype(auto) x = выражение; — и тип выводится по правилам decltype (сохраняются ссылка и const). Удобно в шаблонах для «идеальной передачи» возвращаемого значения.

Почему это источник багов. auto кажется безопасным, но именно он незаметно копирует тяжёлые объекты. Если нужна ссылка без копии — пишите const auto& или auto&. А если копия как раз нужна (чтобы не зависеть от изменений источника) — наоборот, не забывайте её, как в примере ниже.

#include <map>
#include <string>
#include <utility>
#include <vector>

int main() {
    auto i = 42;              // int
    auto d = 3.14;            // double
    auto v = std::vector<int>{1, 2, 3};

    int x = 5;
    int& ref = x;
    const int cx = 10;

    auto a = ref;             // int (копия!) — ссылка потеряна
    auto& b = ref;            // int& — явно берём ссылку
    const auto c = cx;        // const int
    decltype(ref) e = x;      // int& — decltype сохраняет ссылку
    decltype(auto) f = ref;   // int& — идеальная передача типа

    // structured bindings (C++17)
    auto [first, second] = std::pair{1, 2.5};        // int, double
    for (const auto& [key, value] : std::map<std::string, int>{{"a", 1}}) {
        // key, value — ссылки на элементы
    }
    return 0;
}

Шпаргалка: что писать, чтобы получить нужный тип.

auto и его «родственники» (auto&, const auto&, auto&&) — это не отдельные типы, а просьба компилятору вывести тип из инициализатора. Идея в том, чтобы не писать руками монстров вроде std::map<std::string, std::vector<int>>::const_iterator: пусть машина сделает это за нас. В современном C++ это идиоматично по двум причинам: (а) короче код, (б) устойчивость к рефакторингу — если вы поменяете тип возврата функции, auto в точке вызова подстроится автоматически, а явный тип — нет.

Главное, что нужно понять: auto сам по себе не выбирает ни const, ни ссылочность. По умолчанию он возвращает копию значения (то же поведение, что и T x = expr;). Чтобы получить ссылку или запретить изменения, нужно явно попросить: auto&, const auto, auto&& и т. д. Поэтому таблица ниже — это фактически список модификаторов над auto.

Мнемоника. Правило очень простое: «сначала auto, потом — что именно вы хотите получить».

• Нужна копия → просто auto.
• Нужно запретить менять эту копию → добавьте const слева: const auto.
• Нужно работать с оригиналом, без копирования → добавьте &: auto&.
• Нужно и то, и другое → const auto&.
• Нужно переместить во временное хранилище (или написать универсальную шаблонную функцию) → auto&&.

Почему auto& иногда опасен. В range-for auto& item даёт вам изменяемый доступ к элементам контейнера: любое присваивание внутри цикла молча поменяет контейнер. Это редко желаемое поведение, поэтому по умолчанию ставят const. Для «универсальной» функции-шаблона, где lvalue и rvalue обрабатываются одинаково, используют auto&& — это и есть знаменитая forwarding reference (в шаблоне template<class T> void f(T&& x) она «ловит» всё).

Практический совет. В циклах for почти всегда пишите const auto& — это и безопасно (нельзя случайно изменить элемент), и быстро (нет лишней копии). Копию запрашивайте явно, только когда вам действительно нужна независимая локальная переменная.

Structured bindings (C++17). Конструкция auto [a, b] = pair; распаковывает структуру на отдельные переменные. По умолчанию это копии полей; чтобы получить ссылки — пишите auto& [a, b] или const auto& [a, b]. Удобно для пар, кортежей и даже агрегатов.

Где это работает «из коробки».

• std::pair, std::tuple — самый частый случай.
• Агрегаты без приватных полей (struct Point { int x, y; };).
• C-массивы фиксированного размера: int arr[3]{1,2,3}; auto [a,b,c] = arr;.
• У членов вашего типа есть публичный get<N>() или это агрегат — компилятор сам найдёт способ «распаковать».

Старый способ. До C++17 приходилось писать std::tie(a, b) = pair; — он присваивает полям существующих переменных и требует их предварительного объявления. Structured bindings умеют то же самое, но ещё и создают новые переменные с правильным типом. В современном коде используйте auto [...].

Типичная ошибка новичка. const auto& [a, b] = make_pair(); — здесь make_pair() возвращает временный объект, который живёт до конца блока. Это безопасно: ссылка продлевает ему жизнь. А вот auto& [a, b] = make_pair(); — не скомпилируется, потому что нельзя привязать неконстантную ссылку к rvalue. Правило: если справа временное значение — либо const auto&, либо просто auto (копия).

Инициализация фигурными скобками {}: что это и зачем придумана.

Простое определение. {} — это синтаксис «инициализируй объект вот этим списком значений». Появился в C++11, чтобы решить сразу несколько проблем старых способов (T x(value) и T x = value;), которые разрешали тихое «обрезание» типов и неоднозначно работали в некоторых уголках синтаксиса.

Определение. Фигурные скобки {} в C++11+ означают list-initialization — синтаксис «инициализируй объект вот этим списком значений». У него две формы:

• direct: T x{value};
• copy: T x = {value};

Главная суперсила {} — они запрещают сужающие (narrowing) преобразования: int x{3.14}; не скомпилируется, потому что при double → int можно потерять данные. Это ловит целый класс глупых ошибок ещё на этапе компиляции.

Зачем вообще это придумали. До C++11 у программистов было два синтаксиса и оба разрешали тихую потерю точности: double d = 3.14; int x = d; компилировалось, и кто-то мог забыть об этом. С {} та же запись становится ошибкой компиляции — баг ловится до запуска. Вторая причина — «самый неприятный разбор» (см. ниже): {} однозначно выглядит как инициализация, и компилятор не путает её с объявлением функции.

Но у std::vector есть знаменитая ловушка:

#include <vector>

int main() {
    std::vector<int> a(10, 0);   // 10 нулей: конструктор (count, value)
    std::vector<int> b{10, 0};   // два элемента: 10 и 0 — initializer_list выигрывает!
    std::vector<int> c{10};      // один элемент: 10

    int x = 3.14;    // ошибка компилятора: сужение double → int в { }
    int y(3.14);     // 3 — «классическое» сужение разрешено
    double z{7};     // OK: расширение int → double

    // Обнуление через value-initialization
    int* p = new int[100]{};   // все элементы = 0
    return 0;
}

Правило: для большинства объектов используйте {}, но помните, что при наличии initializer_list-конструктора {} выбирает именно его. Для vector(n, value) нужны круглые скобки.

Почему {} «сильнее» круглых скобок. В правилах overload resolution конструктор со std::initializer_list<T> имеет приоритет перед любыми другими подходящими конструкторами, как только компилятор видит {...}. Поэтому vector{10, 0} распознаётся как «список из двух int» и вызывает именно initializer_list-конструктор, а не (count, value). Это поведение иногда называют initializer-list overload priority.

Как это работает «под капотом». Когда компилятор встречает vector<int> b{10, 0};, он сначала смотрит: «есть ли конструктор, принимающий std::initializer_list<int>?» — да, есть. Тогда любой другой конструктор (например, принимающий (size_t, int)) становится запасным вариантом и применяется, только если первый не подходит. У vector оба конструктора могли бы сработать — но initializer_list-версия побеждает по правилам приоритета.

Аналогия из жизни. Представьте, что вы звоните в кафе и делаете заказ. Универсальное меню «любой набор блюд» ({}) — это как комбо-обед: официант предпочтёт его, если вы перечислили блюда списком. Конкретное меню «10 порций одного салата» ((10, 0)) — это уже поштучный заказ: «принесите 10 одинаковых». Если вы скажете «комбо из 10 и 0», официант честно соберёт комбо из двух блюд — а не 10 порций одного.

Как запомнить. Круглые скобки — «вызов конструктора с аргументами» (vector(10, 0) — 10 нулей). Фигурные — «список значений» (vector{10, 0} — два элемента: 10 и 0). Фигурные скобки «сильнее»: если компилятор может прочитать содержимое как список инициализации, он так и сделает.

Простой тест для себя. Перед тем как писать инициализацию, задайте вопрос: «Я говорю что именно передать конструктору (число, размер, символ) — или перечисляю значения, которые должны лечь в объект?» Если перечисляете — {}. Если задаёте параметры — ().

Ещё одна аналогия. Круглые скобки — как заказ в ресторане по меню: «принесите 10 порций одного и того же салата» (vector(10, 0) — 10 нулей). Фигурные скобки — как список покупок: «возьми 10 яблок и 0 груш» (vector{10, 0} — два элемента: 10 и 0). Если в ресторане есть «комбо из списка блюд», официант предпочтёт его — так удобнее.

Частая ловушка. std::vector<int> v{10}; — это вектор из одного элемента со значением 10, а не массив из десяти нулей. Если нужен размер — только круглые скобки: std::vector<int> v(10);. Ошибка коварна тем, что компилируется без предупреждений.

Почему эта ошибка так часто встречается. Программисты по привычке из C/Java/Python ожидают, что {N} означает «массив размера N». В C++ это верно для встроенных массивов (int arr[10];), но не для STL-контейнеров. Хуже того, компилятор не выдаёт предупреждения — с точки зрения языка код корректен, просто семантика не совпадает с интуицией.

Как устроена ошибка в голове. Человек читает {10} и мысленно произносит «вектор из десяти (нулей)». Компилятор же буквально читает {10} как «список из одного элемента — числа 10». Это два разных прочтения одного синтаксиса. Аналогия: если вы скажете другу «купи десять (мороженых)», он поймёт, что вы не уточнили сорт, и купит на свой вкус; компилятор же купит ровно одно мороженое — сорт «десять».

Лайфхак-подсказка. Если вам нужен вектор из N нулей, безопаснее писать с явным , 0 — vector<int> v(N, 0);. Запись vector<int> v{N, 0}; тоже корректна и читается как «два элемента: N и 0», но если N — это переменная, легко спутать с v(N).

Дополнительная защита от самой себя. Если в проекте есть code review, договоритесь о правиле: «для создания пустого контейнера заданного размера — всегда круглые скобки, всегда с явным вторым аргументом». Тогда одна только форма v(N, value) будет сигналом «размер + значение», и эта ловушка исчезнет из кодовой базы.

Когда использовать круглые скобки, а когда фигурные.

Фигурные ({}) — по умолчанию: они запрещают сужающие преобразования (int x{3.14} не скомпилируется) и защищают от «самого неприятного разбора». Круглые (()), когда конструктор явно принимает размер и значение (vector(n, v), string(n, c)) или когда нужен конкретный конструктор без initializer_list.

Общий принцип выбора. Смотрите не на синтаксис, а на намерение:

• «Вот список значений, которые должны лечь в объект» → {}.
• «Вот параметры для конкретного конструктора» → ().

Если оба прочтения возможны, а тип имеет initializer_list-конструктор, по умолчанию побеждает список. Именно поэтому «10 нулей» через {} не получится — компилятор решит, что вы перечислили значения.

Подробная таблица выбора.

Что такое «самый неприятный разбор» (most vexing parse). Старая ловушка из C++03: std::vector<int> v(int()); объявлял не переменную, а функцию, возвращающую vector<int> и принимающую функцию без аргументов. Фигурные скобки (T x{...};) эту проблему снимают — компилятор однозначно видит инициализацию, а не объявление функции.

Почему компилятор так считал. Правило C++ гласит: «если синтаксис может быть и объявлением, и выражением, считай, что это объявление». Конструкция T x(int()) формально подходит под шаблон T x(аргумент), где аргумент — функция int(). Получается объявление функции с именем x. У {} такой двусмысленности нет: T x{...} всегда читается как инициализация.

Пример из реального кода. До C++11 был популярный «заклинательный» способ создания временного объекта: Timer t(Timer::start()); — программист думал, что вызывает конструктор, а компилятор считал, что объявляет функцию t, возвращающую Timer и принимающую результат Timer::start(). После перехода на {} (Timer t{Timer::start()};) двусмысленность исчезает полностью.

Про сужающие преобразования.

• {} — запрещены: int x{3.14}; не компилируется.
• () — разрешены (как и =): int x(3.14); молча отрежет дробную часть.
• int x = 3.14; — компилируется, компилятор может выдать предупреждение -Wnarrowing, но не обязан.

Какие преобразования считаются сужающими. Это любые неявные преобразования, при которых целевой тип гарантированно не вмещает все значения исходного. Классические примеры:

• double → float и double → int (теряется дробная часть).
• long long → int (теряются старшие биты).
• unsigned → signed того же размера (значения «из отрицательной зоны» превратятся в положительные). А расширяющие преобразования (int → double, char → int) — не сужающие, они безопасны и в {} разрешены.

Почему это важно для отладки. Баги типа «int price = 19.99; оказалось 19, потому что забыли умножить на 100» — классика. С {} такой код вообще не скомпилируется, и ошибка найдётся за секунды, а не после жалоб пользователей.

Итоговое правило. Спросите себя: «Я передаю список значений или конкретные аргументы конструктору?»

• Список значений → {}.
• Конкретные аргументы (особенно «размер + значение») → ().
• Сомневаетесь — пишите {}, это безопаснее почти всегда, кроме случаев с initializer_list-ловушкой.

Шпаргалка-резюме на одной строке. По умолчанию {} для всего, что похоже на список или значение, и () — для пар вида «размер + значение» или когда вы точно знаете, что хотите конкретный конструктор без initializer_list. Если сомневаетесь — откройте документацию на конструкторы вашего типа и посмотрите, есть ли среди них initializer_list-версия.

const / constexpr / consteval / constinit / volatile

Простые определения на старте (прочитайте перед подробностями):

• const — контракт «значение не будет изменено после инициализации». Проверяется компилятором: попытка изменить даёт ошибку сборки. Это контракт на этапе компиляции, а не рантайм-защита: значения const всё так же лежат в памяти, и указатель на них в обход типизации (const_cast или низкоуровневый доступ) может изменить данные.
• constexpr — пометка «значение может быть вычислено при компиляции». Это возможность, а не обязанность. Если аргументы известны в compile-time — компилятор посчитает; если нет — функция спокойно отработает в рантайме как обычная.
• consteval (C++20) — пометка «вычисление обязано произойти при компиляции, иначе — ошибка компиляции». Функция не может быть вызвана в рантайме ни при каких условиях.
• constinit (C++20) — гарантия статической (zero/static) инициализации переменной до main, без «dynamic initialization order fiasco». Сама переменная при этом остаётся изменяемой — это не про const, а про порядок инициализации.
• volatile — запрет оптимизаций доступа к памяти; не про потоки и не про атомарность. Каждое чтение/запись происходит как написано — без кеширования в регистрах и без перестановки.

const — обещание не изменять объект во время выполнения. constexpr — вычисление на этапе компиляции. Это разные вещи: constexpr-переменная всегда const, но не наоборот. Аналогия: const — «табличка Не трогать» на готовой вещи, а constexpr — «эту вещь изготовили заранее, ещё на заводе», поэтому её значение подставляется прямо в код и не занимает времени в рантайме. Всё, что можно посчитать заранее, лучше посчитать заранее — так программа работает быстрее и безопаснее. Почему это работает быстрее: вычисления на этапе компиляции не тратят CPU при работе программы, а результат часто вшивается в инструкции (constant folding и constant propagation), позволяя оптимизатору убрать лишние обращения к памяти и арифметику из рантайма. Почему это безопаснее: ошибка в формуле константы ловится компилятором, а не в продакшне — например, static_assert сразу подтвердит, что square(5) == 25, иначе сборка откажет.

#include <array>

constexpr int square(int x) { return x * x; }          // может вычисляться в compile-time
consteval int cube(int x) { return x * x * x; }        // ОБЯЗАН вычисляться в compile-time (C++20)
constinit int counter = 42;                            // инициализация на этапе загрузки, но изменяем (C++20)

int main() {
    const int runtime = 10;           // известно в runtime
    constexpr int compile = square(5);   // 25, вычислено компилятором
    static_assert(compile == 25);        // проверка на этапе компиляции

    std::array<int, square(4)> arr{};    // размер массива — compile-time значение
    // int bad = cube(runtime);          // ошибка: аргумент constexpr не известен
    int good = cube(3);                  // OK: 27
    counter++;                           // constinit НЕ запрещает изменения
    return 0;
}

Что это значит на практике. Выбирайте квалификатор по вопросу «когда известно значение?». Если в рантайме — const. Если при компиляции — constexpr (и заодно получите const). Если обязано вычисляться при компиляции и иначе быть не должно — consteval. Если у глобального объекта есть конструктор, но он не должен ломать порядок инициализации — constinit. volatile — отдельная история: он про «память, которую меняет кто-то извне», а не про потоки. Практический совет: добавляйте constexpr ко всему, что может быть вычислено заранее, — это часто открывает оптимизации и даёт компилятору больше свободы. Почему это работает: constexpr-функция имеет два режима — при compile-time-аргументах она превращается в константу (значение «вшивается» в места использования), при runtime-аргументах работает как обычная функция. Ловушка: constexpr не отменяет правила языка — если тело функции содержит то, что нельзя вычислить при компиляции (например, new или непрослеживаемый вызов), она просто не сработает в compile-time-режиме и станет обычной runtime-функцией. Практический совет: начинайте с constexpr, а consteval используйте только когда нужно заставить компилятор считать заранее (например, чтобы случайный runtime-вызов не замедлил код или не сломал предположения о времени инициализации).

Как запомнить. const — constant (постоянный). constexpr — constant expression (постоянное выражение). consteval — constant evaluation (обязательное вычисление при компиляции). constinit — constant initialization (инициализация на этапе загрузки). Все четыре начинаются с const, но говорят о разных «когда». Мнемоника с конвейером: const фиксирует деталь на месте, constexpr изготавливает её заранее на складе, consteval требует, чтобы деталь обязательно пришла со склада (иначе сборка откажет), constinit гарантирует, что деталь установлена в правильном порядке до запуска конвейера.

На собеседовании спросят.

1. «Чем constexpr отличается от const?» — const говорит «не меняй», constexpr говорит «можно посчитать заранее». constexpr-переменная автоматически const, но обратное неверно: const int n = 5; — значение известно в рантайме точки объявления, но не обязано вычисляться компилятором. Подвох: const int n = rand(); — это валидный код: const гарантирует лишь, что после инициализации n не изменят, но сам rand() исполняется в рантайме и даёт каждый раз новое значение.
2. «Почему constexpr-функцию можно вызвать и в рантайме?» — constexpr-функция способна вычислиться при компиляции, но при вызове с рантайм-аргументом отработает как обычная; consteval же обязан вычисляться всегда. Следствие: если хотите запретить вычисление в рантайме — пишите consteval (C++20); если просто хотите дать компилятору шанс посчитать заранее — пишите constexpr.
3. «Зачем constinit, если есть constexpr?» — constinit нужен для переменных, которые меняются (не const), но должны инициализироваться статически — это страховка от проблемы порядка инициализации глобальных переменных между единицами трансляции (порядок между constexpr-значениями фиксирован, а вот конструкторы с побочными эффектами — нет). Пример пользы: счётчик запросов, инициализированный нулём через constinit, гарантированно стартует с 0 до входа в main, даже если в другой единице трансляции есть глобальный объект, читающий этот счётчик в своём конструкторе.
4. «Чем volatile отличается от std::atomic?» — volatile запрещает оптимизации доступа, но не атомарен и не создаёт happens-before. Для потоков используйте std::atomic или мьютексы; volatile остался только для hardware-регистров и signal-обработчиков. Типичная ошибка: студент защищает флаг volatile bool ready = false; для потока-производителя/потребителя — компилятор и CPU переставят обращения, и второй поток может никогда не увидеть true. Нужен std::atomic<bool> или мьютекс.

const-корректность — часть интерфейса. Метод, не меняющий состояние, помечают const, иначе его нельзя вызвать на const-объекте (или на объекте, пришедшем по const-ссылке — а именно так передают почти всё, чтобы избежать копий). Компилятор проверяет это за вас: чем больше методов помечено const, тем шире класс можно использовать. Члены-данные, которые меняет const-метод (кэш, счётчик обращений), объявляют mutable — это явное «разрешение» менять поле в const-методе. Аналогия из жизни: библиотека — const-метод это библиотекарь, который выдаёт книги и не делает пометок в самих книгах. А mutable — это его карманный блокнот, в котором он записывает, сколько раз выдавал книгу: блокнот принадлежит лично библиотекарю, его изменение не портит состояние книги и не нарушает контракт «объект неизменяем». Типичная ошибка новичка: пометить поле mutable просто потому, что «лень делать метод не-const» — это нарушает контракт: внешний код видит «объект не меняется», а на самом деле меняется его важная часть. Используйте mutable только для того, что логически не является состоянием объекта с точки зрения наблюдателя (кэш, статистика, std::mutex для ленивой синхронизации внутри const-метода).

Ловушка с указателями. const ведёт себя по-разному в зависимости от места в типе — это один из самых частых источников ошибок у новичков:

• const int* p (то же, что int const* p) — указатель на константу: менять *p нельзя, сам p можно переназначить. Аналогия: телевизор в музее — смотреть можно, перенаправить камеру можно, а вот переключать каналы через объектив нельзя.
• int* const p — константный указатель: менять *p можно, сам p переназначить нельзя. Аналогия: камера на штативе — направление менять можно (содержимое по указателю), а вот переставить штатив в другое место нельзя.
• const int* const p — ни то, ни другое. Камера на штативе, направленная в музейный телевизор, которую нельзя ни сдвинуть, ни повернуть.
• const после * защищает указатель, до * — то, на что он указывает. Правило чтения справа налево: сначала имя, потом * (указатель на), потом тип с квалификаторами.

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

class Cache {
    mutable int hits_ = 0;        // можно менять даже в const-методе
public:
    int lookup(int key) const {
        ++hits_;                  // допустимо благодаря mutable
        return key * 2;
    }
    int hits() const { return hits_; }
};

Разбор кода Cache. Поле hits_ помечено mutable, поэтому даже в const-методе lookup его можно инкрементировать. Сам метод lookup при этом не меняет наблюдаемое состояние клиента — он только возвращает key * 2, — но кэширует статистику обращений. Метод hits() тоже const, потому что только читает значение. Без mutable пришлось бы делать lookup не-const, и тогда нельзя было бы вызвать его на const Cache& (а значит, на любом объекте, переданном по const-ссылке). Типичная ошибка: добавить в такой класс поле mutable std::string last_key_; и менять его в lookup, потому что «ну а что такого» — но это уже меняет логическое состояние, и const перестаёт быть гарантией для клиента: внешний код, рассчитывающий на чистую функцию, неожиданно получит побочный эффект.

volatile в современном C++ означает «доступ к памяти нельзя оптимизировать», но не даёт атомарности и не синхронизирует потоки. Для многопоточности используйте std::atomic и мьютексы; volatile оставьте для memory-mapped I/O. Типичная ловушка: многие новички пишут volatile bool flag = false; для флага между потоками — это не работает. volatile не создаёт happens-before связи, не блокирует и не атомарен: компилятор может закэшировать значение в регистре, а CPU — переупорядочить обращения. Между двумя потоками нужен std::atomic<bool> или мьютекс. Когда volatile действительно нужен: регистры периферии (*(volatile uint32_t*)0x40021000), переменные, изменяемые в signal-обработчике (sig_atomic_t исторически используется вместе с volatile), общая память с внешним устройством. Почему компилятор «трогает» память: оптимизатор видит, что в коде переменная явно не меняется, и считает её значение «известным» — может закэшировать его в регистре и не перечитывать из памяти, а также переставить чтение/запись ради скорости. volatile говорит: «не делай этого — значение может стать другим без моего ведома, читай и пиши строго там, где написано». Аналогия: без volatile оптимизатор — это аккуратный клерк, который ведёт блокнот «вот эту переменную я уже смотрел, она равна 5, зачем спрашивать ещё раз?»; с volatile — это строгий наблюдатель, который каждый раз подходит к окну и смотрит наружу заново, даже если вчера уже видел то же самое.

Ссылки, указатели и категории значений

Что такое ссылка и указатель простым языком. Указатель (T*) — это переменная, которая хранит адрес другой переменной в памяти. Сам указатель — обычная переменная (занимает место, может лежать в стеке или куче), а его «значением» является адрес. Ссылка (T&) — это псевдоним (альтернативное имя) уже существующего объекта: она не хранит ничего «отдельно», а просто говорит компилятору «под этим именем работай с тем же объектом». Именно поэтому указатель может быть nullptr (бумажка с адресом, на которой ничего не записано) и переприсваиваться (стёрли старый адрес — написали новый), а ссылка всегда привязана к конкретному объекту и не может быть «нулевой». Технически компилятор чаще всего реализует ссылку тем же указателем «под капотом», но в семантике языка это разные сущности — и в коде, и в правилах языка.

Аналогия, которая снимает половину вопросов. Указатель — это адрес дома, записанный на бумажке: бумажку можно потерять (станет nullptr), стереть и написать другой адрес (переприсваивание), а по адресу дом может уже снести (висячий указатель, dangling pointer). Ссылка — это второе имя человека: у него не бывает «пустого» состояния, переименовать нельзя (привязана раз и навсегда), но зато обращаться по имени всегда безопасно, пока человек жив. Поэтому для параметров функций по умолчанию берут ссылку (безопаснее и понятнее), а указатель — когда значение действительно может отсутствовать или нужна арифметика адресов (как в C-API или при обходе массивов).

#include <iostream>

void by_value(int x)        { x = 42; }        // копия — вызывающий не видит изменения
void by_pointer(int* x)     { if (x) *x = 42; }  // может быть nullptr
void by_reference(int& x)   { x = 42; }          // всегда валидна, не может быть nullptr
void by_const_ref(const std::string& s);         // без копии, не изменяет

int main() {
    int a = 1, b = 2;
    int& r = a;          // r — псевдоним a
    r = 10;              // a == 10
    int* p = &a;         // указатель
    *p = 20;             // a == 20
    int* np = nullptr;   // современная замена NULL и 0
    // int& bad = nullptr;  // ошибка: ссылка не может быть пустой
    return 0;
}

Что это значит на практике. Строка «Может быть пустой» — главное отличие: если функция принимает int*, она обязана проверять if (x) перед разыменованием (иначе — UB, undefined behaviour), а если int& — проверка не нужна, ссылка всегда валидна по контракту. Поэтому параметр-указатель «сигнализирует» вызывающему, что аргумент необязателен, а параметр-ссылка — что обязателен. Это негласный договор между автором и пользователем функции, и его полезно соблюдать: не заставляйте вызывающего думать «а вдруг там nullptr?», если по логике объект всегда есть. Исключение — const T&, которая служит заменой «передать по значению, но без дорогого копирования».

Когда использовать, а когда нет. Практическое правило:

• const T& — для чтения больших объектов (std::string, std::vector, структуры): дешёвая передача без права изменения.
• T& — когда функция должна изменить аргумент и это часть её публичного контракта (например, swap, операторы >>/<<).
• T* — когда значение опционально, нужно указать на массив, либо вы работаете с C-API, который диктует указатели.
• T (по значению) — для маленьких типов (int, double, указатели), когда нужна именно локальная копия или когда тип настолько дешёв, что ссылка только усложнит код.

Типичная ошибка новичка — брать T& для маленьких типов «на всякий случай». Это не даёт выигрыша (ссылка внутри — тот же указатель) и ломает удобство вызова с временными значениями.

Категории значений — это классификация выражений (не переменных!), которая говорит компилятору: можно ли с этого выражения «украсть» внутренние ресурсы объекта (буфер строки, элементы вектора) или нет. Зачем это нужно — чтобы при возврате из функций, в конструкторах и операторах присваивания выбирать между дорогим копированием и дешёвым перемещением. Существует три основных категории: lvalue (именованный объект), prvalue (чистое временное значение, pure rvalue), xvalue (объект, помеченный std::move, из которого можно перемещать, expiring value).

выражение
        /       \
   glvalue     rvalue
   /    \      /    \
lvalue  xvalue    prvalue

• lvalue — x, arr[0], *p, результат ++i: имеет имя и адрес, живёт дальше.
• prvalue — 42, x + y, f() при возврате по значению: чистый временный объект, который вот-вот умрёт.
• xvalue — std::move(x), static_cast<T&&>(x): lvalue, помеченный как «перемещаемый», его ресурсы можно забирать.

Как запомнить. l — left (стоит слева от =, у него есть имя и адрес), r — right (стоит справа, временное). x — expiring (истекающее, скоро можно забрать ресурсы). На практике из всей теории важны только два вопроса:

1. «Можно ли из этого безопасно украсть ресурсы?» — да, если это xvalue или prvalue (объект временный или явно помечен для перемещения); нет, если lvalue (объект ещё нужен).
2. «Переживёт ли объект выражение?» — prvalue не переживёт, поэтому любой указатель/string_view/ссылка на него — опасна; lvalue переживёт — и с ним работать безопасно.

#include <utility>
#include <string>

void take_copy(std::string s);              // копирует переданное
void take_ref(std::string& s);              // lvalue-ссылка: только именованные
void take_move(std::string&& s);            // rvalue-ссылка: только временные

template <typename T>
void forwarder(T&& arg) {                   // forwarding reference (не rvalue-ссылка!)
    take_copy(std::forward<T>(arg));        // сохраняет категорию значения
}

int main() {
    std::string s = "hello";
    take_copy(s);            // копия
    take_copy(std::move(s)); // перемещение (s в «валидном, но неопределённом» состоянии)

    std::string a = "x";
    std::string b = std::move(a);   // b забрал буфер; a пуст (обычно), но НЕ трогайте его
    return 0;
}

Reference collapsing — правило схлопывания ссылок: & & → &, & && → &, && & → &, && && → &&. Зачем оно нужно? Ссылок на ссылку в C++ формально нет — но при подстановке шаблонных параметров такие комбинации возникают постоянно, и без правила компилятор не знал бы, во что превращать int& & или int& &&. Именно поэтому T&& в шаблоне может стать lvalue-ссылкой, если передан lvalue: при выводе T = int& и схлопывании int& && → int&. Этот механизм — фундамент «универсальных ссылок».

template <typename T> void f(T&&);   // forwarding reference
// f(x) с int x  → T = int&,   параметр int&   (lvalue передаётся по ссылке)
// f(5)          → T = int,    параметр int&&  (rvalue передаётся как rvalue)

Почему T&& в шаблоне — особенное. Снаружи это выглядит как обычная rvalue-ссылка, но в шаблоне T&& называется forwarding reference (раньше говорили universal reference): компилятор выводит T так, чтобы сохранить категорию аргумента. Передали именованный объект — T = int&, и с учётом схлопывания (& && → &) параметр становится int&. Передали временный — T = int, параметр остаётся int&&. Именно это позволяет одной функции принимать «что угодно» и через std::forward<T> передавать дальше без потери категории значения — иначе вложенный вызов всегда видел бы lvalue или всегда rvalue, и мы бы теряли эффективность перемещений.

Частая ловушка. T&& — универсальная ссылка только если T выводится компилятором из аргумента. Если тип известен заранее (void g(std::string&&)) или есть дополнительные квалификаторы (void g(const std::vector<T>&&), void g(MyClass<T>&&) где T указан явно) — это обычная rvalue-ссылка. Не путайте эти случаи — от них зависит, скомпилируется ли передача lvalue: в rvalue-ссылку std::string&& нельзя передать именованную переменную, а в forwarding reference — можно.

std::move — это просто static_cast<T&&>, то есть приведение к rvalue-категории. Сам он ничего не перемещает: ни память не копирует, ни поля не обнуляет. Он лишь разрешает компилятору выбрать перемещающий конструктор/оператор присваивания вместо копирующего — если такой вообще есть.

std::forward — похожий каст, но работает только при определённых условиях (тип выводится) и сохраняет исходную категорию значения в шаблонном коде. Использовать std::forward вне шаблонов — почти всегда ошибка.

Частая ловушка — «std::move ничего не делает». Новичок пишет std::move(x) и ждёт, что объект «сам собой опустеет». На самом деле std::move лишь разрешает компилятору выбрать перемещающий конструктор/присваивание. Если у типа нет таких операций (например, у const-объекта или у типа без поддержки move, как старые структуры с полями только для чтения), произойдёт обычное копирование — молча, без ошибки и без предупреждения. Поэтому правило: std::move осмыслен только там, где адресат умеет перемещаться, а вы после перемещения не трогаете источник.

Почему std::move опасен на const. Если объект помечен const, то после std::move вы получаете const std::string&&. А перемещающий конструктор принимает не-константную ссылку (std::string&&) и не подходит — снова вызывается копирующий. Никакой ошибки компиляции, просто молча теряете эффективность. Практический вывод: не помечайте объекты const, если собираетесь их перемещать, и не пишите std::move(const_var) в надежде на выигрыш.

// Продление жизни временного объекта (lifetime extension):
const std::string& bad()  { return std::string("temp"); }   // ОШИБКА: висячая ссылка
std::string good()        { return std::string("temp"); }   // OK: копия/перемещение

int main() {
    const int& r = 42;              // OK: константная ссылка продлевает жизнь prvalue
    const std::string& s = "abc";   // OK: временный объект живёт столько же, сколько s
    // но это НЕ работает через параметр функции:
    // void sink(const std::string&); sink("abc");  // временное умирает в конце выражения
    return 0;
}

Как запомнить правило продления жизни. Константная ссылка, привязанная к временному объекту при инициализации переменной, продлевает его жизнь до конца области видимости этой переменной. Но если временный объект передан в параметр функции — он живёт только до конца выражения с вызовом: параметр функции — это не «инициализация переменной» в смысле lifetime extension, он лишь принимает значение. Отсюда знаменитая ошибка: сохранить const std::string& на результат s1 + s2 безопасно (временный продлевается), а вернуть такую ссылку из функции — нет (временный создаётся в кадре вызывающей функции, ссылка возвращается в никуда, после выхода — висячая). Если хотите вернуть строку — возвращайте по значению: компилятор применит NRVO и перемещение, и эффект будет даже лучше, чем ссылка.

На собеседовании спросят. «Почему ссылка не может быть nullptr?», «Чем const T& лучше передачи по значению?», «Что такое dangling reference?» — базовый набор по теме; держите в голове аналогию «адрес дома / второе имя».

Классы и ООП

Что такое класс и зачем он нужен. Класс — это пользовательский тип данных, который объединяет данные (поля, data members) и поведение (методы, member functions) в одной сущности. По умолчанию члены class — private, члены struct — public. Это, по сути, единственное синтаксическое различие между class и struct в C++: и там, и там можно писать поля, методы, наследование, виртуальные функции — всё что угодно. Класс отвечает на три вопроса: «какие данные хранит объект?», «что он умеет делать?» и «что из этого видно снаружи?».

Аналогия из жизни. Класс объединяет данные и поведение. По умолчанию члены class — private, члены struct — public. Аналогия: класс — это чертёж дома, а объект (экземпляр) — сам дом, построенный по чертежу; можно построить сколько угодно домов, и у каждого будут свои значения полей. Метод класса — это инструкция из чертежа: «как открыть дверь», «как посчитать площадь». Статическое поле — «общий двор» на все дома, а не у каждого дома свой.

Зачем нужна инкапсуляция. Сокрытие данных (private) — это «закрытая проводка»: снаружи видно только выключатели (публичные методы), а внутренности нельзя испортить напрямую. Если бы все провода торчали наружу, любой мог бы случайно замкнуть сеть. Через private пользователь работает только через безопасный интерфейс, а разработчик класса может менять реализацию (например, перейти с std::vector на std::deque внутри), не ломая внешний код. В этом и состоит главная практическая выгода ООП: можно менять внутренности, сохраняя контракт.

#include <string>
#include <utility>

class Account {
public:
    Account(std::string owner, double balance)   // список инициализации членов
        : owner_(std::move(owner)), balance_(balance) {}   // порядок = порядок объявления!

    void deposit(double amount) {                // неявный this
        if (amount > 0) balance_ += amount;      // this->balance_
    }

    [[nodiscard]] double balance() const { return balance_; }      // const-метод
    static int accounts_created() { return count_; }               // статический метод

private:
    std::string owner_;          // порядок объявления задаёт порядок инициализации
    double balance_ = 0.0;       // инициализатор по умолчанию
    mutable int reads_ = 0;      // можно менять из const-методов
    static int count_;           // одно поле на весь класс
};

int Account::count_ = 0;         // определение статического члена

class Tagged {
    friend void inspect(const Tagged&);   // friend получает доступ к private
    int secret_ = 7;
};

void inspect(const Tagged& t) { /* может читать t.secret_ */ }

Что это значит на практике. struct в C++ — это тот же класс, просто с публичными членами по умолчанию; выбирайте struct для «простых данных без инвариантов» (Point, Config, пары координат) и class, когда есть внутреннее состояние, которое нужно защищать. Хорошее правило: если в типе есть хоть один метод, проверяющий корректность полей, — это class, потому что поля должны быть private. explicit — ваш друг: он превращает случайную неявную конвертацию в ошибку компиляции. Без explicit компилятор молча создаст временный объект там, где вы этого не хотели (например, передадите double вместо Meters). [[nodiscard]] спасает от классического бага, когда функция возвращает статус ошибки или новый объект, а вызывающий код его забывает использовать — компилятор сам напомнит.

Когда использовать, а когда нет. static-метод — для операций, не зависящих от конкретного объекта (фабрика, утилита, подсчёт созданных экземпляров). Если метод логически работает с данными объекта — делайте его обычным, чтобы он мог обращаться к полям через this. friend — только когда без него интерфейс получается кривым: классический пример — перегрузка operator<< для потокового вывода, где левый аргумент std::ostream не наш, и без friend к приватным полям не добраться. Злоупотребление friend разрушает инкапсуляцию: если у вас десяток friend-классов, скорее всего, дизайн стоит пересмотреть и вынести общую логику в отдельный компонент. mutable — для служебных полей (кэш, счётчик обращений, ленивая инициализация), которые не меняют наблюдаемое состояние объекта, но нужны для оптимизации.

Про this и static-члены. this — неявный указатель на объект, для которого вызван метод; внутри const-метода он имеет тип const T*, поэтому из const-метода нельзя менять обычные поля (кроме mutable). Это гарантирует, что константный объект действительно останется неизменным после вызова метода. Именно поэтому константность «заразна»: const-метод может вызывать только другие const-методы и обращаться только к const-ссылкам и const-указателям. static-поле — одно на весь класс, а не на объект: оно существует даже без созданных экземпляров и требует определения вне класса (int Account::count_ = 0;), иначе линкер выдаст undefined reference. Это частое первое сообщение об ошибке у новичков: «я объявил static int count_ в классе, а он не линкуется» — компилятор про декларацию знает, а линковщик не видит самого определения.

Как запомнить. Обычный член — «у каждого дома своя дверь», static — «один общий подъезд на все дома». this — «этот конкретный дом». private — «за закрытой дверью, ключ только у хозяина и его friend-друзей». mutable — «чёрная метка: это поле можно трогать даже у константного дома».

Ловушка: порядок инициализации членов задаётся порядком их объявления в классе, а не порядком в списке инициализации. Компилятор предупредит (-Wreorder), но молчаливое нарушение — источник трудноуловимых багов, если один член инициализируется значением другого: вы читаете ещё не сконструированное поле.

class Bad {
    int b_;
    int a_;
public:
    Bad(int v) : a_(v), b_(a_) {}   // ОШИБКА: b_ инициализируется ДО a_!
    // реально: b_ = мусор, a_ = v
};

// explicit спасает от неявных преобразований
class Meters {
    double value_;
public:
    explicit Meters(double v) : value_(v) {}
};
// void f(Meters m);
// f(3.0);                        // ошибка благодаря explicit
// f(Meters{3.0});                // OK — явно

Почему порядок инициализации так устроен. Компилятор инициализирует члены ровно в том порядке, в котором они объявлены в классе, — потому что физическое расположение полей в памяти тоже задаётся порядком объявления, а конструктор обязан построить их по одному, как кирпичи в стене снизу вверх. Список инициализации лишь задаёт значения, он не меняет порядок: компилятор сначала смотрит на тело класса, расставляет члены по их фактическому порядку и только потом применяет рецепт из списка. Если один член инициализируется значением другого, а объявлен раньше — вы читаете ещё не построенное поле, то есть мусор из памяти. Именно поэтому b_(a_) при int b_; int a_; даёт b_ мусор: b_ инициализируется первым, когда a_ ещё не существует. Компилятор GCC/Clang выдаст -Wreorder, но не ошибку — код соберётся и упадёт в рантайме, иногда только под нагрузкой или на другой платформе:

class Bad {
    int b_;                       // объявлен ПЕРВЫМ — значит инициализируется первым
    int a_;
public:
    Bad(int v) : a_(v), b_(a_) {} // a_ ещё не инициализирован → b_ = мусор
};

Как запомнить. «Список инициализации — это не порядок, а рецепт». Читайте его глазами, но верьте только порядку объявления полей. Правило гигиены: держите список в том же порядке, что и объявления, тогда предупреждений -Wreorder не будет вовсе и баг с зависимыми полями не возникнет физически. Если два поля зависят друг от друга — это сигнал, что архитектуру класса стоит пересмотреть: либо вынесите зависимость в метод после конструктора, либо пересмотрите порядок объявления.

Специальные функции-члены

Определение. Специальные функции-члены (special member functions) — это функции, которые компилятор может сгенерировать за вас для управления жизненным циклом объекта: его созданием, копированием, перемещением и уничтожением. Вы их явно не пишете, но они всё равно существуют — как невидимые помощники, которые знают, что делать с каждым объектом.

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

Зачем их вообще выделяют. Любой объект в C++ живёт по расписанию: его нужно сконструировать, иногда скопировать (например, при передаче в функцию по значению), иногда переместить (когда промежуточная копия больше не нужна) и в конце — уничтожить. Если программист забывает правильно описать эти шаги для класса, владеющего ресурсом (памятью, файлом, сокетом), возникают классические ошибки: утечки памяти, двойное освобождение, use-after-free. Спец. функции — это точки, в которых вы «перехватываете» эти шаги, чтобы всё сделать корректно. Аналогия из жизни. Спец. функции — это договор аренды квартиры: въезд (конструктор), подселение соседа (копирование), переезд в другую квартиру (перемещение) и выезд с уборкой (деструктор). Если хотя бы один пункт договора забыт — жди проблем.

Правило нуля: не пишите спец. функции вручную — пусть члены (std::string, std::vector, std::unique_ptr) управляют ресурсами. Правило трёх: если нужен деструктор, нужны и копирующий конструктор, и копирующее присваивание. Правило пяти (C++11): добавьте перемещающие конструктор и присваивание.

Как применять на практике. Начинайте с правила нуля: возьмите std::string вместо char*, std::vector вместо int*, std::unique_ptr вместо сырого указателя — и компилятор сам напишет за вас все пять функций. Если по каким-то причинам это невозможно (вы пишете собственный контейнер или низкоуровневую RAII-обёртку над ресурсом) — переходите к правилу пяти: пишите все пять явно. Типичная ошибка новичка — выучить только правило трёх и в современном C++11-коде забыть о перемещающих операциях: в итоге std::vector начинает копировать вместо того, чтобы перемещать, и теряется вся выгода от C++11.

Почему эти правила существуют. Правило трёх возникло в C++98: если объект владеет ресурсом (например, указателем на буфер), деструктор обязан его освободить, но тогда и копирование должно создать свою копию ресурса, иначе два объекта начнут удалять его дважды (double free). В C++11 добавились перемещающие операции — так правило стало «пятью». А правило нуля — это его эволюция: пусть ресурсами владеют готовые члены, и тогда ни одну из пяти функций писать не придётся. Аналогия: не храните деньги в кармане сами — положите их в банк (RAII-обёртку), и банк сам позаботится о сохранности.

Историческая справка. В C++98 правило формулировалось как «правило трёх» — без перемещений. Тогда, если вы писали класс с деструктором, было принято сразу писать и копирующий конструктор, и копирующее присваивание. Когда в C++11 появились rvalue-ссылки и std::move, к правилу добавились ещё две функции, и оно стало «правилом пяти». Одновременно сообщество осознало, что чаще всего эти функции вообще не нужно писать вручную — достаточно использовать готовые RAII-обёртки (std::string, std::vector, std::unique_ptr), и компилятор всё сделает сам. Так появилось правило нуля — самое современное и рекомендуемое к применению по умолчанию.

#include <algorithm>
#include <cstddef>
#include <utility>

class Buffer {
public:
    explicit Buffer(std::size_t n) : size_(n), data_(new int[n]{}) {}

    ~Buffer() { delete[] data_; }                                  // 1. деструктор

    Buffer(const Buffer& other)                                    // 2. копирование
        : size_(other.size_), data_(new int[other.size_]) {
        std::copy(other.data_, other.data_ + size_, data_);
    }

    Buffer& operator=(const Buffer& other) {                       // 3. копирующее присваивание
        if (this != &other) {                                      // защита от self-assignment
            Buffer tmp(other);                                     // copy-and-swap
            swap(tmp);
        }
        return *this;
    }

    Buffer(Buffer&& other) noexcept                                // 4. перемещение
        : size_(other.size_), data_(other.data_) {                 // не копируем — забираем
        other.data_ = nullptr;
        other.size_ = 0;
    }

    Buffer& operator=(Buffer&& other) noexcept {                   // 5. перемещающее присваивание
        if (this != &other) {
            delete[] data_;
            size_ = other.size_;
            data_ = other.data_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }

    void swap(Buffer& other) noexcept {
        std::swap(size_, other.size_);
        std::swap(data_, other.data_);
    }

private:
    std::size_t size_;
    int* data_;
};

Разбор ключевых приёмов. if (this != &other) в присваивании защищает от a = a: без проверки мы сначала удалили бы собственный буфер, а потом скопировали данные из уже удалённого — use-after-free. Аналогия: представьте, что вы переставляете содержимое двух коробок и по ошибке передаёте функции одну и ту же коробку дважды — без проверки вы выбросите всё в мусор ещё до того, как начнёте перекладывать. copy-and-swap (создать копию, затем обменять её с собой) даёт strong guarantee: если копирование бросит исключение, исходный объект останется нетронутым, ведь мы ещё ничего не меняли. Почему именно так, а не new + delete напрямую? Путь «выделить новый буфер → скопировать → удалить старый» плох тем, что при исключении в new или copy мы уже потеряли старые данные. copy-and-swap инвертирует порядок: сначала строим новые данные во временном объекте, и только когда они гарантированно готовы — обмениваем. В перемещающем конструкторе важно забрать указатель и обнулить чужой (other.data_ = nullptr), иначе деструктор other дважды освободит тот же буфер. Практический совет. После перемещения «источник» должен находиться в валидном, но неопределённом состоянии — обычно это означает «пусто», чтобы его можно было безопасно уничтожить или присвоить заново.

// =default и =delete управляют генерацией
struct MoveOnly {
    MoveOnly() = default;
    MoveOnly(const MoveOnly&) = delete;              // копировать нельзя
    MoveOnly& operator=(const MoveOnly&) = delete;
    MoveOnly(MoveOnly&&) = default;                  // перемещать можно
    MoveOnly& operator=(MoveOnly&&) = default;
};

Когда это нужно. Типичный пример MoveOnly — классы, владеющие уникальным ресурсом: std::unique_ptr, std::thread, std::mutex, файловые дескрипторы. Копировать их бессмысленно (кому достанется право владения?), а вот переместить — естественно: «передать» владение другому объекту. Если случайно попытаетесь скопировать такой класс, компилятор выдаст ошибку прямо в месте вызова — это лучше, чем двойное освобождение в рантайме.

Подводный камень №1 — noexcept у move. Если перемещающий конструктор не помечен noexcept, std::vector при росте копирует, а не перемещает элементы (strong exception guarantee). Это может превратить O(n) роста в O(n²) и заметно замедлить программу.

struct HeavyNoexcept {
    HeavyNoexcept(HeavyNoexcept&&) noexcept = default;   // vector будет перемещать — быстро
};
struct HeavyThrowing {
    HeavyThrowing(HeavyThrowing&&) {}                    // без noexcept → vector копирует
};

Почему это так. При росте vector выделяет новый буфер и переносит туда элементы. Если перемещение может бросить исключение и бросит на середине, восстановить исходное состояние невозможно — часть элементов уже перемещена. Чтобы дать строгую гарантию, vector заранее проверяет noexcept перемещающего конструктора и, если её нет, предпочитает копирование: копию можно отбросить, оригинал цел. Аналогия: переезд с хрупкой мебелью — грузчики сначала делают копию мебели, а не рискуют перевезти оригинал и разбить его. Практический совет. Почти все пользовательские move-конструкторы и move-присваивания должны быть noexcept — они только «отбирают» указатели у источника, а это не бросает. noexcept — это контракт: вы обещаете компилятору и стандартной библиотеке, что операция не бросит, и они вам за это дают более агрессивные оптимизации.

На собеседовании спросят. «Почему std::move_if_noexcept существует и где применяется?» Ответ: именно vector (и другие контейнеры) через него решают, перемещать элемент или копировать, чтобы сохранить strong exception guarantee. Разбор по шагам. move_if_noexcept<T>(x) возвращает static_cast<T&&>(x) если у T есть noexcept-move-конструктор, иначе — const T&. То есть функция «отдаёт» перемещаемость только тогда, когда она безопасна; иначе «отдаёт» только константную ссылку, по которой можно только скопировать. Внутри vector::push_back это выглядит как: «новый элемент создаётся через move_if_noexcept, старый буфер копируется или перемещается в новый — и если что-то пойдёт не так, старый буфер всё ещё цел».

Подводный камень №2 — правило пяти «ломает» генерацию. Объявив деструктор, вы подавляете генерацию перемещающих операций, а объявив перемещение — копирующих. Итоговая матрица:

Что это значит на практике. Таблица читается так: объявив что-то одно, вы неявно «выключаете» генерацию другого. Самый частый сюрприз — строка «Деструктор»: автор добавил ~Foo() для логирования, и перемещение исчезло — все std::vector<Foo> внезапно стали копироваться, а std::sort по элементам — тормозить. Лечится одной строкой: Foo(Foo&&) = default; Foo& operator=(Foo&&) = default;. Типичная ошибка. Программист добавляет пустой деструктор ~Foo() {} «на всякий случай» или для трассировки — и сразу получает катастрофу с производительностью в std::vector<Foo>. Компилятор не предупредит, профилировщик не сразу покажет причину, а виновник — безобидная пустая функция. Практический совет. Если вам нужен только лог в деструкторе — пишите его отдельной функцией-членом и вызывайте её явно, а сам деструктор оставляйте сгенерированным компилятором (= default).

Как запомнить. «Объявил деструктор — потерял перемещение». «Объявил перемещение — потерял копирование». Хотите и то и другое — объявите явно или, лучше, вообще не пишите спец. функции (правило нуля). Мнемоника. Запомните три ключевых слова-триггера: деструктор, копирование, перемещение. Любое из них «выбивает» из генерации то, что стоит правее в цепочке «копирование → перемещение». Исключение — =delete: явный запрет не подавляет генерацию того, что не упомянуто, поэтому =delete копирования оставляет перемещение живым (последняя строка таблицы). Практический совет на каждый день. Перед тем как добавить в класс любую из пяти спец. функций, спросите себя: «точно ли мне нужно писать её вручную?» В большинстве случаев ответ — нет, и тогда применяется правило нуля.

Наследование и полиморфизм

Простое определение. Наследование — это способ описать, что один класс (например, Circle) является частным случаем другого (Shape), автоматически получив все его поля и методы. Полиморфизм — это способ одним и тем же вызовом (s->area()) выполнить разный код в зависимости от того, какой именно объект стоит за указателем: круг, квадрат или треугольник.

Наследование моделирует «является» (public). Виртуальные функции дают динамический полиморфизм: вызов выбирается во время выполнения по реальному типу объекта через таблицу vtable. Это ключ ко всему ООП в C++: вы пишете код, работающий с базовым типом (Shape), а он в рантайме вызывает правильную реализацию (Circle::area) — не зная заранее, какие фигуры появятся.

Аналогия из жизни. Представьте пульт от кондиционера с кнопкой «охладить». Сам пульт один (базовый интерфейс), но в зависимости от того, к какой модели сплит-системы он подключён, реакция будет разной: одни модели начнут дуть на 16°, другие — на 18°. Для пользователя важно только нажать кнопку, а «как именно охлаждать» — решает конкретное устройство в рантайме. Это и есть полиморфизм: один интерфейс — много реализаций.

Что такое vtable и зачем она нужна. Когда объект создаётся, компилятор кладёт первым скрытым полем указатель на таблицу виртуальных функций — массив адресов конкретных реализаций. Аналогия: это таблица маршрутов в аэропорту; самолёт (объект) один, но по какому маршруту (функции) лететь в конкретном случае — определяется записью в таблице. Вызов s->area() превращается в «загляни в таблицу и перейди по адресу» — отсюда небольшая цена динамической диспетчеризации. Без virtual компилятор подставил бы адрес во время компиляции (раннее связывание), и вызов всегда попадал бы в базовую версию.

Почему vtable — это плата за гибкость. Компилятор не знает заранее, какой именно объект будет лежать в vector<unique_ptr<Shape>>, поэтому не может «зашить» адрес вызова прямо в код. Ему приходится в рантайме: (1) прочитать указатель vptr из объекта, (2) заглянуть в нужную ячейку vtable, (3) перейти по найденному адресу. Это три косвенных обращения к памяти вместо одного прямого вызова. На практике процессоры хорошо предсказывают такие переходы, и накладные расходы обычно невелики — но в горячих циклах миллионы виртуальных вызовов могут стать узким местом.

#include <iostream>
#include <memory>
#include <string>
#include <vector>

class Shape {
public:
    virtual ~Shape() = default;                  // ВИРТУАЛЬНЫЙ деструктор обязателен!

    virtual double area() const = 0;             // чистая виртуальная → абстрактный класс
    virtual std::string name() const { return "shape"; }   // можно переопределить
};

class Circle : public Shape {
public:
    explicit Circle(double r) : r_(r) {}
    double area() const override { return 3.14159 * r_ * r_; }   // override проверяет сигнатуру
    std::string name() const override { return "circle"; }
private:
    double r_;
};

class UnitCircle final : public Circle {         // final: от этого класса нельзя наследовать
public:
    UnitCircle() : Circle(1.0) {}
};

int main() {
    std::vector<std::unique_ptr<Shape>> shapes;
    shapes.push_back(std::make_unique<Circle>(1.0));
    shapes.push_back(std::make_unique<Circle>(2.0));

    for (const auto& s : shapes) {
        std::cout << s->name() << ": " << s->area() << '\n';   // динамическая диспетчеризация
    }
    return 0;
}

Что это значит на практике. virtual включает динамическую диспетчеризацию и стоит лишнего обращения к памяти — поэтому не помечайте виртуальным всё подряд. override не влияет на работу программы, но ловит опечатку в сигнатуре: без него вы бы получили новую функцию, а не переопределение, и полиморфизм молча перестал бы работать. dynamic_cast дорог (проверка в рантайме) и требует RTTI; в горячем коде его избегают, предпочитая виртуальные методы или std::variant.

Практические подсказки по таблице.

• virtual — плата идёт за возможность вызова через базовый указатель. Если вы всегда работаете с конкретным типом — virtual не нужен и даже вреден.
• override — пишите его ВСЕГДА при переопределении. Это «бесплатная страховка»: компилятор проверит, что сигнатура совпадает с базовой функцией (имя, тип возврата, параметры, константность). Если что-то не так — получите ошибку компиляции, а не молчаливый баг.
• final — ставится на метод, чтобы запретить его переопределение в наследниках, или на класс, чтобы запретить дальнейшее наследование. Помогает оптимизатору (он знает, что больше переопределений не будет) и проектировщику (явно фиксирует намерения).
• = 0 — делает класс абстрактным: нельзя создать объект такого типа. Используется для определения интерфейса без реализации.
• dynamic_cast — работает только для полиморфных типов (тех, у которых есть хотя бы одна виртуальная функция). Возвращает nullptr для указателей и бросает std::bad_cast для ссылок, если приведение не удалось.
• typeid — возвращает std::type_info. Требует RTTI, может быть отключён флагом -fno-rtti.

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

Принцип «является» vs «имеет». Публичное наследование выражает отношение «is-a»: круг ЯВЛЯЕТСЯ фигурой, поэтому везде, где ожидается Shape, можно передать Circle. Отношение «has-a» (машина ИМЕЕТ двигатель) выражается композицией — полем класса. Наследование для «has-a» — частая ошибка новичков, которая ведёт к хрупкому дизайну и проблемам с модификацией иерархии.

Подводный камень №1 — нет виртуального деструктора. Удаление производного объекта через указатель на базу с невиртуальным деструктором — UB: производная часть не будет разрушена, ресурсы утекут.

class Base { public: ~Base() {} };                 // НЕ виртуальный
class Derived : public Base { std::string big_; };

Base* p = new Derived();
delete p;   // UB: ~Derived() не вызван, big_ утечёт

Почему это происходит. delete p вызывает деструктор по статическому типу указателя (Base), если деструктор не виртуальный. Производная часть объекта (big_) остаётся неразрушенной, её память и ресурсы утекают. С виртуальным деструктором вызов пойдёт через vtable и попадёт в ~Derived(), а тот автоматически вызовет ~Base().

Аналогия. Представьте, что вы сдаёте в аренду дом через агентство. Агентство знает только адрес дома (базовый указатель), но не знает, что внутри — мебель, техника, животные. Если агентство при «выселении» просто закроет дверь и уйдёт (невиртуальный деструктор), то животные останутся запертыми (утечка). Если агентство сначала войдёт, выпустит животных, вывезет мебель, а потом закроет дом (виртуальный деструктор с правильной цепочкой) — всё будет в порядке.

Типичная ошибка новичков. Пишут ~Base() = default; без virtual и думают, что «деструктор есть — и хорошо». Но именно virtual заставляет компилятор строить цепочку вызовов деструкторов от производного к базовому. Без этого слова — цепочка не строится, и компилятор «срезает» объект до базового типа.

На собеседовании спросят. «Когда нужен виртуальный деструктор?» Ответ: всегда, когда через указатель/ссылку на базу можно удалить объект производного типа. Правило-мнемоника: «есть хотя бы одна виртуальная функция — делай виртуальный деструктор».

Подводный камень №2 — object slicing. При копировании производного объекта в базовый по значению теряется производная часть.

void print(Shape s);              // по значению — ПЛОХО
void print(const Shape& s);       // по ссылке — правильно

std::vector<Shape> shapes;        // ПЛОХО: все элементы «срежутся» до Shape
std::vector<std::unique_ptr<Shape>> good;   // правильно: указатели сохраняют тип

Почему это происходит. Когда вы передаёте объект по значению, компилятор копирует только ту часть, которая «видна» через статический тип. Если статический тип — Shape, то копируется только «кусок» Shape, а специфичные поля Circle (например, r_) просто отбрасываются. Получается новый объект типа Shape без какой-либо информации о радиусе. Аналогия: если вы сфотографируете только лицо человека, а потом по фото попытаетесь узнать его рост — информации нет, она «срезалась».

Как распознать на собеседовании. Если видите функцию void foo(Base b) без ссылок и указателей — это красный флаг. Любой полиморфизм через такую функцию невозможен: всё «срежется».

Подводный камень №3 — виртуальный вызов в конструкторе/деструкторе. Во время работы базового конструктора объект ещё имеет базовый тип, поэтому вызов virtual попадёт в базовую версию (или в чисто виртуальную — с падением). Никогда не вызывайте виртуальные методы из конструкторов и деструкторов.

class Base {
public:
    Base() { init(); }                 // вызовется Base::init, а не производный!
    virtual void init() { std::cout << "base\n"; }
};

class Derived : public Base {
public:
    void init() override { std::cout << "derived\n"; }   // НЕ будет вызван из ctor
};
// Derived d; → печатает "base"

Почему так устроено. Когда выполняется базовый конструктор, производная часть объекта ещё не инициализирована — её просто не существует. Если бы компилятор вызвал Derived::init, тот мог бы прочитать неинициализированные поля и упасть, или хуже — получить UB. Поэтому стандарт C++ явно требует, чтобы виртуальные вызовы в конструкторах и деструкторах «деградировали» до статического типа на текущем уровне иерархии. Аналогия: пока фундамент дома строится, нельзя красить крышу — крыши ещё нет.

Практический совет. Если вам нужна «инициализация» с использованием данных производного класса — вынесите её в отдельный метод, который пользователь должен вызвать сам после конструктора (например, шаблон «двухфазная инициализация» или «initializer»). Либо используйте статический полиморфизм (шаблоны) — там такой проблемы нет.

Множественное наследование даёт несколько базовых подобъектов; если два пути ведут к одному базовому классу, используют виртуальное наследование (virtual Base), чтобы был один общий подобъект — так решается «ромб». dynamic_cast при этом корректно переходит между ветвями.

Аналогия с ромбом. Представьте генеалогическое древо, где у человека два родителя, и оба происходят от одного общего предка (например, общего прадеда). Без виртуального наследования у объекта было бы две копии «прадеда» — и непонятно, к какой из них обращаться. Виртуальное наследование говорит: «у этого предка должна быть только одна копия, общая для всей иерархии».

Почему ромб — это сложно. Виртуальное наследование решает дублирование базового подобъекта, но: (1) конструктор самого виртуального базового класса должен вызываться напрямую из самого производного класса (обычно это MostDerived), а не из промежуточных; (2) доступ к полям виртуальной базы чуть медленнее из-за дополнительного уровня косвенности; (3) приведение типов dynamic_cast требует обхода структуры vtable.

Как запомнить три главных ловушки. «Нет virtual ~ — утечёт память». «Копируешь по значению — срежешь производную часть». «Вызываешь virtual в конструкторе/деструкторе — попадёшь в базовую версию». Эти три вопроса — любимая тема интервью и источник реальных багов.

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

Практический совет по дизайну. Если хочется множественное наследование для «скрещивания» реализаций — лучше подумать о композиции, шаблоне «стратегия» или миксинах на шаблонах (CRTP). Множественное наследование интерфейсов (например, class Circle : public Shape, public Drawable, public Serializable) — нормальная практика, потому что интерфейсы не содержат данных и не дают ромба. А вот множественное наследование классов с данными — почти всегда признак плохого дизайна.

Полиморфизм: динамический или статический?

Дополнительные критерии выбора.

• Бинарная совместимость плагинов. Динамический полиморфизм позволяет загружать модули (.so, .dll), написанные независимо: они реализуют известный интерфейс и регистрируются в фабрике. Шаблоны так не умеют — они требуют код конкретного типа в момент компиляции.
• Размер бинарника. Шаблоны раздувают код: 10 разных типов в vector<T> — это 10 разных версий каждого шаблонного метода. Виртуальные функции — одна реализация, но каждая единица трансляции тащит vtable.
• Отладка. Виртуальные вызовы удобнее отлаживать: стек вызовов показывает реальный тип объекта. В шаблонах после инлайнинга стек может быть «развёрнут» в одну функцию.
• Анализ кода. Статические анализаторы лучше работают с шаблонами: всё известно на этапе компиляции. Виртуальные вызовы требуют анализа всех возможных наследников, что часто невозможно в больших проектах.

Гибридный подход — std::variant и std::visit. Если нужна коллекция разнородных объектов, но без vtable и RTTI, рассмотрите std::variant (из C++17): это типобезопасное объединение фиксированного набора типов. std::visit позволяет вызвать нужную реализацию без динамической диспетчеризации — компилятор строит таблицу переходов один раз. Это компромисс между скоростью шаблонов и гибкостью виртуальных функций.

Итоговая мнемоника. «Нужны разные типы в одной коллекции и выбор в рантайме — virtual. Тип известен заранее и нужна скорость — шаблон. Набор типов фиксирован, но лень писать иерархию — variant.» Как запомнить. Это два разных инструмента для двух разных задач — выбирай по ситуации, а не по принципу «что круче».

Быстрая аналогия. Представь, что ты организуешь обед:

• virtual — это шведский стол: одна большая «тарелка-массив», на которую разные повара (классы) кладут блюда любых видов. Ты берёшь тарелку и накладываешь в неё всё подряд — Circle, Rectangle, Triangle. Тарелка одна, блюда разные.
• Шаблоны — это конвейер на фабрике: ты заранее знаешь, какие формы печёшь (круги или прямоугольники), и для каждой формы отдельная, идеально подогнанная линия. Скорость максимальная, но переоборудовать линию на ходу нельзя.

Правило выбора

Почему так работает

• virtual добавляет косвенность: при вызове метода компилятор сначала смотрит в таблицу виртуальных функций (vtable), чтобы найти нужную реализацию. Это один лишний прыжок по указателю и невозможность заинлайнить вызов — зато работает для любого наследника.
• Шаблоны убирают эту косвенность: код «размножается» на этапе компиляции под каждый конкретный тип, поэтому компилятор видит всё и может жёстко оптимизировать. Плата — раздутый бинарник и время компиляции.

Типичные ошибки

• «Использую шаблон, чтобы хранить разные фигуры в одном векторе». Не получится: std::vector<Shape<T1, T2, ...>> — это разные типы, а не один. Для коллекции разных фигур нужен virtual или std::variant.
• «Делаю virtual ради пары известных типов, потому что "так универсальнее"». Потеряешь в скорости зря — фиксированный набор типов эффективнее обработать шаблоном или if constexpr.
• «Пишу чисто виртуальный класс, но забываю virtual в деструкторе базы». Удаление объекта через указатель на базу приведёт к утечке памяти в наследниках. Деструктор в полиморфном классе обязан быть virtual.
• «Считаю, что virtual — это медленно, а шаблоны — всегда быстро». В реальности virtual — это один лишний прыжок по указателю, на современных CPU он часто предсказуем и почти бесплатен. Преждевременная оптимизация через шаблоны без профилирования обычно вредит читаемости кода.

Перегрузка операторов

Определение. Перегрузка операторов — это механизм C++, который позволяет задать собственное поведение встроенных операторов (+, <<, ==, (), [] и т. д.) для пользовательских типов. Технически оператор — это обычная функция с «магическим» именем вида operator@ (например, operator+, operator==); компилятор вызывает её вместо встроенного поведения, когда хотя бы один из операндов — объект вашего класса.

Аналогия из жизни. Универсальный калькулятор умеет складывать числа. Вы хотите, чтобы он также «понимал» координаты точек, матрицы или денежные суммы. Перегрузка — это инструкция калькулятору: «вот как работать с моим типом». Сам калькулятор остаётся тем же, но набор операций расширяется под ваши данные. Главное — не заставляйте его «вычитать», когда пользователь нажал «+»: такое поведение ломает интуицию и приводит к багам, которые невозможно отловить на этапе компиляции.

Операторы — это функции с особыми именами. Перегружайте только там, где синтаксис естественен: + для чисел, == для сравнения, << для вывода. Не давайте operator+ семантику удаления.

Зачем это нужно. Перегрузка позволяет пользовательскому типу вести себя как встроенный: Vec2 a, b; a + b читается понятнее, чем a.add(b). Принцип «наименьшего удивления» — главный: программист, увидев +, ожидает сложение, а не удаление. Если оператор не имеет очевидного смысла для типа (например, * для «соединить строки»), лучше назвать метод словами.

Как это устроено «под капотом». Когда компилятор встречает a + b, он ищет подходящую функцию operator+ сначала среди методов класса a (если a — ваш тип), затем среди обычных функций в текущей области видимости и в пространствах имён, связанных с типами аргументов. Эта последняя «ветка» называется ADL (Argument-Dependent Lookup, поиск по аргументам) — именно благодаря ей std::cout << vec находит дружественную функцию operator<<, объявленную внутри класса Vec2. Если ничего не найдено, компилятор пробует встроенные операторы (например, для int + int) либо сообщает об ошибке.

#include <compare>
#include <iostream>
#include <ostream>

class Vec2 {
public:
    Vec2(double x, double y) : x_(x), y_(y) {}

    Vec2 operator+(const Vec2& other) const {      // член класса
        return Vec2{x_ + other.x_, y_ + other.y_};
    }

    Vec2& operator+=(const Vec2& other) {
        x_ += other.x_;
        y_ += other.y_;
        return *this;                              // возвращаем ссылку на себя
    }

    bool operator==(const Vec2& other) const = default;   // C++20: сравнение членов

    auto operator<=>(const Vec2& other) const = default;  // C++20: лексикографический порядок

    friend std::ostream& operator<<(std::ostream& os, const Vec2& v) {   // друг
        return os << '(' << v.x_ << ", " << v.y_ << ')';
    }

private:
    double x_, y_;
};

int main() {
    Vec2 a{1, 2}, b{3, 4};
    std::cout << a + b << '\n';        // (4, 6)
    std::cout << (a == b) << '\n';     // 0
    std::cout << (a < b) << '\n';      // 1 (по operator<=>)
    return 0;
}

На что смотреть в этом коде.

• operator+ возвращает новый объект по значению: арифметика не должна менять операнды.
• operator+= возвращает Vec2& на *this — это разрешает цепочку a += b += c.
• operator== и operator<=> объявлены = default (C++20): компилятор сравнивает все поля автоматически и безопасно.
• operator<< сделан friend-ом, потому что его левый операнд — поток, а не наш класс.

Что это значит на практике. operator<< нельзя сделать членом, потому что левый операнд — поток std::ostream, а не ваш тип; поэтому его объявляют свободной функцией или friend. Операторы =, [], (), -> синтаксис языка требует делать членами. operator<=> (трёхстороннее сравнение, «космический корабль») в C++20 автоматически порождает <, <=, >, >= — писать шесть операторов сравнения вручную больше не нужно.

Как выбирать: член класса, свободная функция или friend.

• Метод класса — когда оператор логически «принадлежит» типу и должен видеть приватные поля. Удобно для унарных (-a), составного присваивания (+=), а в C++20 — для <=> и ==.
• Свободная функция — когда один из операндов «чужой» (std::ostream) или когда критична симметрия (a + b и b + a без неявных преобразований правого операнда).
• friend-функция — компромисс: свободная функция, но с доступом к приватным полям. Используется для operator<<, operator>> и симметричной арифметики.

Почему для operator== безопаснее свободная функция. Если operator== — метод, в выражении a == b компилятор сначала пробует неявно привести b к типу a: асимметрия, неожиданные конверсии и сюрпризы при наследовании. Свободная функция bool operator==(const Vec2&, const Vec2&) обрабатывает оба операнда одинаково, что особенно важно в иерархиях классов.

Когда использовать, а когда нет. Перегружайте, если операция очевидна и часто используется. Не перегружайте &&, || (теряется короткое замыкание), , (ломает привычный смысл) и не давайте operator== несимметричную семантику.

Почему &&, || и , перегружать нельзя. Встроенные операторы гарантируют порядок вычисления: a && b пропускает b, если a ложно (короткое замыкание), а a, b всегда вычисляет a первым. Любая функция в C++ обязана вычислить все аргументы до вызова — компилятор не знает, что внутри «логика», поэтому короткое замыкание теряется. По этой же причине стандарт C++ запрещает перегрузку &&, || и , синтаксически: компилятор выдаст ошибку «cannot overload operator ...», если вы попробуете.

Инкремент и декремент различают по фиктивному параметру int:

class Counter {
    int n_ = 0;
public:
    Counter& operator++()    { ++n_; return *this; }        // префиксный: ++c
    Counter  operator++(int) { Counter old = *this; ++n_; return old; }  // постфиксный: c++
    int value() const { return n_; }
};

Почему префиксный без аргументов, а постфиксный — с int. C++ должен отличать ++a (префикс: сначала увеличить, вернуть новое значение) от a++ (постфикс: запомнить старое, увеличить, вернуть старое). Чтобы не вводить два разных имени, ввели фиктивный параметр int у постфиксной формы. Само значение int внутри не используется — это лишь «метка» для компилятора; по соглашению туда передаётся 0, но читать его не нужно.

Практический совет. В циклах всегда предпочитайте префиксный ++ постфиксному: for (Counter c; ...; ++c). Префиксный работает «на месте» и возвращает ссылку — без копирования. Постфиксный обязан сохранять старую копию, что для сложных типов обходится лишними тактами и аллокациями. То же касается итераторов стандартной библиотеки: для итераторов произвольного доступа префиксная форма почти всегда дешевле.

Ловушка — операторы преобразования. Неявный operator bool или operator int может привести к неоднозначностям; в C++11 и позже помечайте их explicit — тогда они сработают только в контексте, где нужен именно этот тип.

Почему это ловушка. Без explicit компилятор выполнит неявное преобразование везде, где оно синтаксически допустимо: в арифметике (h + 1), при передаче в функцию с другим типом параметра, в тернарных выражениях. Это одна из самых коварных причин загадочных ошибок: «почему мой Handle молча складывается с целым числом?». С explicit неявного пути нет, и каждая конвертация требует явного static_cast или контекста, где тип действительно требуется.

class Handle {
    int fd_;
public:
    explicit operator bool() const { return fd_ >= 0; }   // работает в if, но не в арифметике
};
// if (h) { ... }                     // OK
// int x = h + 1;                     // ошибка — и это хорошо

Почему explicit здесь обязателен. Без него operator bool сработал бы в любом арифметическом контексте: h + 1, h * 2, передача в функцию, ожидающую int. Это порождает неоднозначности перегрузок и логические ошибки, которые компилятор не заметит. С explicit преобразование происходит только там, где язык действительно требует булево значение (if, while, !, &&, ||) — что и нужно.

Где explicit разрешает преобразование.

• В условии if (h), while (h), for (; h; ).
• В логических операциях !h, h && cond, h || cond.
• В тернарном операторе cond ? h : default_value, где один из операндов явно bool.
• В static_assert(h), noexcept(h), delete[] — позиции, где синтаксически требуется bool. И не работает: в арифметике, при инициализации другим типом (bool b = h;), в return x; из функции, возвращающей int.

Аналогия. Handle — это «детектор ошибок». Вы хотите, чтобы в if он сообщал «есть ошибка?», но не хотите, чтобы его случайно использовали как число (handle + 5). explicit — это замок: открывается только там, где «дверь» ведёт именно в булеву проверку.

На собеседовании спросят. «Почему operator bool делают explicit?» и «Чем explicit-конструктор отличается от explicit operator T?» Оба вопроса — про контроль над неявными преобразованиями; ответ один: explicit запрещает «случайные» конвертации, оставляя только явные.

Как развернуть ответ.

• explicit-конструктор: запрещает неявное создание объекта из другого типа. Handle h = 5; не скомпилируется, а Handle h(5); или Handle h{5}; — да.
• explicit operator T: запрещает неявное превращение нашего типа в T. bool b = h; не скомпилируется, а if (h) { ... } — да, потому что язык явно требует bool. Общий принцип: неявные преобразования — это скрытые баги; лучше писать static_cast явно, чтобы код читался однозначно.

Что ещё могут спросить.

• «Зачем operator<=> называют «космическим кораблём»?» — символ <=> похож на кораблик, а сам оператор «отправляет» два значения в трёх направлениях: меньше / равно / больше. Возвращаемый тип — обычно std::strong_ordering, std::weak_ordering или std::partial_ordering.
• «Можно ли сделать operator+ виртуальным?» — нет. Виртуальность работает только для методов с диспетчеризацией по *this; свободные операторы не виртуальны. Полиморфное копирование делается через виртуальный clone() или virtual конструктор копирования.
• «Чем operator+ отличается от operator+=?» — первый создаёт новый объект, второй изменяет левый операнд и возвращает ссылку на него. Стандартная идиома: operator+ через operator+= (T a = lhs; a += rhs; return a;).
• «Нужно ли перегружать && и ||?» — нет, и это запрещено синтаксически ради сохранения короткого замыкания.

Частые ошибки при перегрузке.

• Несимметричный operator==. Сравнение a == b и b == a должно давать одно и то же. Лучше делать свободной функцией с двумя const&. Если operator== — метод, неявные преобразования работают только для правого операнда — это асимметрия, особенно неприятная при наследовании и при типах с explicit-конструкторами.
• Забытый return *this в operator+=. Теряется цепочка a += b += c, а иногда и корректность. Компиляция пройдёт, но (a += b) += c либо не скомпилируется (потому что возвращается void), либо молча выбросит изменённую копию — баг проявится только в больших выражениях, искать его неприятно.
• operator+ изменяет операнд. Арифметические операторы должны возвращать новый объект, а не менять исходный. Это нарушает интуицию (1 + 2 не меняет 1) и ломает работу с временными объектами и const-корректностью. Идиома: T operator+(T a, const T& b) { a += b; return a; }.
• Неявные преобразования без explicit. Приводят к неоднозначностям перегрузок. Компилятор может выбрать «не ту» перегрузку из цепочки неявных приведений, и ошибка всплывёт далеко от места создания.
• Перегрузка &&, ||, ,. Теряется короткое замыкание и привычный порядок вычисления. В C++ это официально запрещено синтаксисом — компилятор выдаст ошибку «cannot overload operator &&», но знать об этом полезно, чтобы понимать, почему.
• operator<< как член класса. Не компилируется, потому что слева стоит поток, а не ваш объект. Синтаксис os << a требует, чтобы operator<< был найден в области видимости std::ostream или найден через ADL; метод класса a тут недоступен — компилятор выбирает функцию до того, как «заходит» внутрь a.

Дополнительные ошибки, которые часто всплывают.

• Лишний const на операторе, который должен мутировать. operator++() без const — нормально; если пометить его const, ++n_ внутри не скомпилируется, потому что меняется состояние объекта.
• Игнорирование noexcept. Арифметика над «лёгкими» типами (Vec2, int) почти всегда noexcept — это помогает компилятору оптимизировать и безопасно для исключений. Для типов с аллокациями (std::string + std::string) noexcept снимается, и это нормально.
• Передача по значению там, где достаточно const&. Лишние копии; для больших типов это ощутимо. Но: для типов размером с два double (Vec2) компилятор часто оптимизирует передачу по значению в регистрах — здесь это безопасно.
• Возврат по значению ссылки на локальный объект. return Vec2{...}; — нормально, объект живёт в возвращаемом значении. return *new Vec2{...}; — утечка памяти.
• Сравнение через operator== для типов с плавающей точкой без эпсилон-точности. Vec2(0.1+0.2) == Vec2(0.3) почти всегда false из-за ошибок округления. Для вещественных чисел используйте std::almost_equal или сравнение с эпсилон-окрестностью.

Как запомнить. «Постфиксный ++ берёт фиктивный int», «+= возвращает ссылку на себя», «<< — друг, а не член». Три эти фразы закрывают большинство вопросов по теме.

Расширенная мнемоника.

• +, -, *, /, %, ==, !=, <, >, <=, >= — бинарные, могут быть членами или свободными. Выбирай свободную функцию, если нужна симметрия.
• =, [], (), -> — только члены: так требует синтаксис (первый операнд — *this).
• +=, -=, *=, /= — только члены: они изменяют левый операнд и должны иметь к нему доступ.
• <<, >> для потоков — только свободные: левый операнд «чужой».
• <=>, ==, != в C++20 — члены с = default, остальные операторы сравнения порождаются автоматически.
• Префиксный ++ — без аргументов; постфиксный ++ — с фиктивным int.
• Любой оператор, который не меняет данные, помечай const.
• Любой оператор, изменяющий левый операнд, возвращает T& на *this.

Экспресс-чеклист перед коммитом.

1. Все операторы сравнения либо написаны вручную, либо получены из = default (<=>).
2. Арифметические операторы (+, -, *) не меняют операнды и возвращают новое значение.
3. Составное присваивание (+=, -= и т. п.) возвращает T& на *this.
4. operator<< для вывода объявлен как friend или свободная функция.
5. Операторы преобразования помечены explicit (если только намеренно не нужны неявные конверсии).
6. Бинарные операторы, не меняющие операнды, имеют const-квалификацию (если они — члены).
7. Симметричные операторы (a + b и b + a) выражены свободной функцией.
8. Для типов с плавающей точкой сравнение идёт через эпсилон, а не через ==.

RAII и умные указатели

Определение. RAII (Resource Acquisition Is Initialization, «захват ресурса есть инициализация») — это центральная идиома C++, в которой ресурс (память, файл, мьютекс, сетевое соединение, дескриптор ОС) захватывается в конструкторе объекта и автоматически освобождается в его деструкторе. Идиома опирается на детерминированное время жизни локальных объектов: как только переменная выходит из области видимости, её деструктор вызывается гарантированно. Именно это делает C++ безопаснее, чем C, и удобнее, чем языки с try/finally.

RAII — центральная идиома C++: ресурс захватывается в конструкторе и освобождается в деструкторе. Всё, что имеет пару acquire/release (new/delete, open/close, lock/unlock), оборачивают в класс. std::unique_ptr, std::shared_ptr и std::lock_guard — готовые RAII-обёртки.

Аналогия и смысл. RAII — это «уборщик, который приходит автоматически»: вы не пишете free, close, unlock руками, потому что при выходе объекта из области видимости компилятор сам вызывает деструктор. Представьте библиотеку: вы берёте книгу и получаете «талон» (объект RAII); как только вы выходите из читального зала (область видимости), талон автоматически списывает книгу обратно — никакого ручного возврата, штрафа за забытую книгу нет. Работает это благодаря гарантии языка: при выходе из блока, при return, при исключении (раскрутка стека) деструкторы локальных объектов вызываются всегда. Поэтому RAII — единственный способ писать код, безопасный к исключениям, без ручных try/finally (которых в C++ и нет — в отличие от Java, Python и C#, где приходится явно закрывать файлы в finally). До RAII в C использовали ручные пары open/close и надеялись, что программист ничего не забудет; в современном C++ такой код считается ошибкой проектирования.

#include <memory>
#include <iostream>

struct Resource {
    Resource()  { std::cout << "acquire\n"; }
    ~Resource() { std::cout << "release\n"; }
    void use()  { std::cout << "use\n"; }
};

int main() {
    // unique_ptr: единоличное владение, нулевой оверхед, нельзя копировать
    auto up = std::make_unique<Resource>();
    up->use();
    // auto copy = up;                 // ошибка: копирование запрещено
    auto moved = std::move(up);        // передача владения

    // shared_ptr: разделяемое владение через счётчик ссылок
    auto sp = std::make_shared<Resource>();
    auto sp2 = sp;                     // счётчик = 2
    std::cout << "use_count=" << sp.use_count() << '\n';   // 2

    // weak_ptr: наблюдает, не влияет на время жизни — разрывает циклы
    std::weak_ptr<Resource> wp = sp;
    if (auto locked = wp.lock()) {     // временно получить shared_ptr
        locked->use();
    }
    return 0;   // здесь вызовутся деструкторы
}

Что это значит на практике. «Владение» (ownership) — это ответ на вопрос «кто отвечает за удаление объекта и когда он будет уничтожен». Это самая важная концепция в управлении памятью: каждый объект в программе должен иметь ровно одного «хозяина», который знает, когда пора удалять (либо нескольких хозяев, договорившихся через счётчик ссылок). unique_ptr — один хозяин, поэтому его нельзя копировать (иначе появилось бы два хозяина на один объект и непонятно, кто удаляет), зато можно перемещать (передать владение). shared_ptr — несколько хозяев, объект удалится, когда счётчик ссылок упадёт до нуля; цена — атомарные (потокобезопасные, но не бесплатные) инкременты/декременты счётчика и control block — служебная структура с самим счётчиком, удалителем и аллокатором. weak_ptr ничего не удаляет, только «подсматривает» в живой shared_ptr, поэтому им разрывают циклические ссылки (например, в графах и деревьях). Правило выбора простое: начинайте с unique_ptr, а shared_ptr берите только если владение действительно разделяется между независимыми частями программы, которые не знают друг о друге заранее. Перейти с unique_ptr на shared_ptr легко (через std::move), обратно — почти невозможно без перепроектирования интерфейсов.

Как запомнить. unique — один (англ. «уникальный»), shared — общий (англ. «разделяемый»), weak — слабый (англ. «слабый», не влияет на время жизни). use_count() показывает, сколько shared_ptr смотрят на объект — это отладочный инструмент; в продакшен-коде полагаться на его конкретное значение нельзя, потому что в многопоточной программе оно может измениться сразу после чтения в соседнем потоке.

Готовые RAII-обёртки стандартной библиотеки.

Вывод. Почти любой «ручной» захват ресурса имеет готовую RAII-обёртку в <memory>, <mutex>, <fstream>, <thread> и контейнерах STL. Если пишете lock()/unlock() или open()/close() руками — скорее всего, вы изобретаете то, что уже есть, и рискуете забыть освобождение на одной из веток (особенно при исключениях — компилятор не напомнит). Золотое правило современного C++: никакого голого new/delete, malloc/free, fopen/fclose, lock/unlock в прикладном коде — всё через RAII-обёртки, иначе вы платите за безопасность, которую компилятор мог бы обеспечить бесплатно.

Подводный камень №1 — циклы shared_ptr. Два объекта, ссылающихся друг на друга через shared_ptr (например, родитель → ребёнок → обратно к родителю в дереве), никогда не освободятся: счётчик каждого объекта в цикле никогда не станет нулём, потому что они держат друг друга живыми. Одно из рёбер делают weak_ptr — обычно ссылку «от ребёнка к родителю», потому что родитель и так владеет ребёнком и не нуждается в обратной сильной ссылке. Это классический источник утечек памяти в графовых структурах, который не видно глазом без профилировщика.

Подводный камень №2 — make_shared vs new. std::make_shared<T>() выделяет объект и control block одним блоком памяти: быстрее (одна аллокация вместо двух) и исключительно-безопасно (нет временного окна, когда объект уже создан, но shared_ptr ещё не сформирован — если между этими шагами бросится исключение, объект потеряется). Но weak_ptr держит весь блок живым (там лежит control block), поэтому долгоживущие weak_ptr к большим объектам лучше не смешить с make_shared: память под сам объект не освободится, пока жив последний weak_ptr, даже если все shared_ptr уже умерли. В таком редком случае лучше использовать std::shared_ptr<T>(new T(...)) — две отдельные аллокации, зато тело объекта освобождается, как только умирает последний shared_ptr.

// enable_shared_from_this: получить shared_ptr на себя внутри метода
class Node : public std::enable_shared_from_this<Node> {
public:
    std::shared_ptr<Node> self() { return shared_from_this(); }   // только если объект уже в shared_ptr
    // std::shared_ptr<Node> bad() { return std::shared_ptr<Node>(this); }  // ПЛОХО: двойное удаление
};

Почему нельзя shared_ptr<T>(this). Такой указатель создаёт второй control block со своим независимым счётчиком, ничего не зная о первом. Когда оба счётчика дойдут до нуля, объект будет удалён дважды — double free, классическое неопределённое поведение: чаще всего это краш, реже — тихое повреждение кучи, которое проявится через полчаса в не связанном с этим месте программы. enable_shared_from_this решает проблему: он даёт доступ к существующему control block через shared_from_this(), поэтому счётчик один на всех владельцев. Вызывать shared_from_this() можно только после того, как объект уже принадлежит shared_ptr (в конструкторе — нельзя: control block ещё не создан; в деструкторе — поздно, объект уже умирает). Правило: если у класса есть метод, возвращающий shared_ptr на себя (this), класс обязан наследоваться от enable_shared_from_this, иначе — UB.

На собеседовании спросят. «В чём разница между unique_ptr и shared_ptr?», «Почему цикл из shared_ptr течёт?», «Что будет, если сделать два shared_ptr из одного сырого указателя?» — все три вопроса про модель владения, и ответы стоит держать в голове дословно. Готовые формулировки: (1) «unique_ptr — единоличный владелец, нулевой оверхед, нельзя копировать, можно перемещать; shared_ptr — разделяемое владение через атомарный счётчик, дороже, можно копировать»; (2) «Потому что счётчик каждого объекта в цикле никогда не станет нулём — одно из рёбер должно быть weak_ptr»; (3) «Два независимых control block, двойной delete — UB, нужен make_shared или enable_shared_from_this для безопасного создания shared_ptr на this».

Сырые new/delete нужны в редких случаях. placement new конструирует объект в заранее выделенной памяти:

#include <new>

struct Node { int value = 0; };

alignas(Node) unsigned char buffer[sizeof(Node)];   // выровненная сырая память
Node* n = new (buffer) Node{42};                    // сконструировать на месте
n->~Node();                                         // деструктор вызвать вручную
// delete n — НЕЛЬЗЯ: память не из new

Зачем это нужно. placement new конструирует объект в уже выделенном буфере, не запрашивая память у системного аллокатора. Это применяют в пулах памяти (memory pool), аренах, контейнерах фиксированной ёмкости (когда заранее известно максимальное число элементов и выделен массив unsigned char), при работе с shared memory между процессами и в ядре ОС, где динамическая аллокация запрещена или недопустимо дорога. Плата — ручное управление временем жизни: деструктор вызывается явно (n->~Node()), а delete применять нельзя, потому что память выделена не через new. Если вызвать деструктор дважды (double destroy) или не вызвать вовсе (забыть) — неопределённое поведение: use-after-free или утечка. Ещё одна тонкость: буфер должен быть правильно выровнен (alignas(Node)), иначе на платформах со строгим выравниванием (ARM, AVX-инструкции на x86) обращение к полям класса даст crash или очень медленную эмуляцию выравнивания. Помните: new (buffer) T{...} только конструирует, он не выделяет память — за память отвечает ваш код.

Когда использовать, а когда нет. В обычном коде placement new не нужен — берите std::vector, std::optional или std::aligned_storage. Если вы добавляете его «для скорости» без измерений (профилирования), вы просто усложняете код и получаете источник трудноуловимого UB. Практическое правило: используйте placement new только там, где требуется (а) zero-allocation в горячем коде реального времени, (б) работа с разделяемой памятью ОС (mmap, shm), (в) реализация собственного контейнера с фиксированным capacity, (г) embedded-системы без кучи. Во всех остальных случаях стандартные аллокаторы работают быстрее, чем кажется (особенно с tcmalloc/jemalloc), и с ними невозможно ошибиться в подсчёте деструкторов. Сигнал, что вы зря применяете placement new: вы пишете комментарий-напоминание «не забудь вызвать деструктор» — значит, пора остановиться и взять std::vector.

Исключения

Исключение — это специальный объект, который «вылетает» из функции в момент ошибки и летит по стеку вызовов вверх, пока его кто-нибудь не поймает через catch. Такой механизм нужен, чтобы передавать информацию об ошибке через границы функций без обязательной проверки возвращаемого кода.

Механизм работы: при броске (throw) среда выполнения начинает раскручивать стек вызовов в обратном порядке. На каждом уровне для всех полностью построенных локальных объектов вызываются деструкторы (это и есть работа принципа RAII — Resource Acquisition Is Initialization: «захват ресурса есть инициализация»), затем управление передаётся ближайшему подходящему catch-блоку.

Зачем нужны исключения. Вернуть код ошибки можно и в C-стиле, но тогда вызывающий обязан проверять его на каждом вызове — одну проверку забыли, и ошибка поехала дальше, превратившись в загадочный сбой далеко от места. Исключение же нельзя проигнорировать: если никто не поймал, программа завершится.

Аналогия из жизни: код ошибки — это записка, которую можно потерять по дороге; исключение — пожарная сирена, которую слышат все, пока кто-то не нажмёт «отбой» (catch).

Мини-словарь терминов:

• Бросить исключение (throw) — создать объект-исключение и запустить его вверх по стеку.
• Поймать исключение (catch) — перехватить его в подходящем обработчике.
• Раскрутка стека (stack unwinding) — процесс вызова деструкторов на пути от throw к catch.
• Тип исключения — определяет, какой именно catch его поймает (по совпадению типа в catch-объявлении).

#include <iostream>
#include <stdexcept>
#include <string>

double divide(double a, double b) {
    if (b == 0.0) {
        throw std::invalid_argument("деление на ноль");   // бросаем объект-исключение
    }
    return a / b;
}

int main() {
    try {
        std::cout << divide(10, 0) << '\n';
    } catch (const std::invalid_argument& e) {            // ловим по const-ссылке!
        std::cerr << "Ошибка: " << e.what() << '\n';
    } catch (const std::exception& e) {                   // общий случай — последним
        std::cerr << "Стандартная ошибка: " << e.what() << '\n';
    } catch (...) {                                       // перехват всего
        std::cerr << "Неизвестная ошибка\n";
    }
    return 0;
}

Разбор по строкам:

• try открывает «зону наблюдения»: всё, что вылетит внутри, будет поймано нижестоящими catch.
• Порядок catch важен: проверка идёт сверху вниз, от более конкретного типа к более общему. Поэтому catch (...) всегда стоит последним.
• catch (const std::exception& e) ловит всё семейство стандартных исключений, потому что они наследуются от std::exception.
• Метод e.what() возвращает C-строку с описанием ошибки — это общий интерфейс для всех стандартных исключений.

Как исключение работает вместе с RAII. Раскрутка стека — это «обратный проход»: выходя из каждой функции на пути к catch, среда вызывает деструкторы всех построенных локальных объектов. Посмотрите:

#include <fstream>
#include <stdexcept>

void process() {
    std::ifstream in("data.txt");          // RAII: файл откроется
    if (!in) throw std::runtime_error("нет файла");

    std::vector<int> buffer(1000);         // RAII: память выделится
    // ... если здесь бросить исключение — файл закроется
    // и память освободится АВТОМАТИЧЕСКИ, без try/catch внутри process()
}

Никаких try внутри process нет, но при любом исключении (или return) buffer и in будут корректно уничтожены. Это и есть смысл RAII: ресурсы освобождаются не там, где «удобно программисту», а гарантированно при любом выходе из функции — нормальном (дошли до конца) или аварийном (исключение).

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

Что это значит на практике. Иерархия std::exception даёт единый интерфейс: e.what() возвращает текст, и вы можете ловить как конкретный тип, так и всю ветку через базовый. Это удобно для организации обработчиков по принципу «от частного к общему».

logic_error — это «ошибка в коде, её нужно исправить» (например, индекс вне диапазона), её не имеет смысла «обрабатывать» в рантайме — корректное решение состоит в исправлении бага. runtime_error — «внешние обстоятельства» (нет файла, отвалилась сеть), её как раз ловят и повторяют попытку либо сообщают пользователю.

Почему иерархия устроена именно так? Это позволяет писать универсальный код: библиотека может бросить любой наследник std::exception, а пользовательский код — поймать его одним catch (const std::exception& e) и достать сообщение через what(). Без такой иерархии каждая библиотека изобретала бы свой тип ошибки и свой способ узнать её описание, и обработка превратилась бы в ад.

Как запомнить. logic — вина программиста (баг в коде), runtime — вина окружения (внешний мир подвёл). Наследуйте свои исключения от std::runtime_error/std::logic_error, чтобы их можно было поймать общим catch (const std::exception&). Это правило хорошего тона: ваши исключения станут «гражданами» стандартной иерархии.

Совет: для своих типов исключений делайте то же, что делает стандартная библиотека — наследуйтесь от подходящего базового класса и передавайте сообщение в конструктор базового класса через std::string.

Гарантии безопасности исключений — это контракт между классом и его пользователями: класс обещает, в каком состоянии останется объект, если во время операции вылетит исключение.

• Nothrow (no-throw guarantee) — операция не бросает никогда. Помечается ключевым словом noexcept. Самая сильная гарантия.
• Basic (basic guarantee) — при исключении объект остаётся в валидном, но, возможно, изменённом состоянии. Никаких утечек, объект можно использовать дальше, но данные могут быть «не те».
• Strong (strong guarantee) — операция либо выполняется целиком, либо полностью откатывается (как транзакция в базе данных). Чаще всего реализуется через идиому copy-and-swap.

Как запомнить уровни. Думайте про откат транзакции: nothrow — «операция не умеет падать»; basic — «при падении объект цел, но состояние могло измениться»; strong — «либо всё, либо ничего, как с банковским переводом». Контейнеры STL обычно дают strong guarantee для вставки в vector (через noexcept move или копирование), а вот push_back у vector без move-noexcept сползает к basic.

Почему это важно? Если вы пишете функцию, которая меняет сразу несколько полей объекта, вы обязаны ответить себе на вопрос: «А что увидит пользователь, если на пятом шаге вылетит исключение?» Ответ и есть уровень гарантии, который вы обещаете в документации.

Подводный камень №1 — деструкторы noexcept по умолчанию. Деструктор неявно noexcept, и если он бросит во время раскрутки стека, программа завершится через std::terminate. Никогда не позволяйте деструкторам бросать: логируйте и глотайте, либо явно помечайте noexcept(false) (и не используйте такой объект в раскрутке).

Почему так строго? Раскрутка стека — это уже обработка одного «активного» исключения. Если в этот момент прилетает второе исключение из деструктора, то непонятно, какое из двух считать текущим, как их связать и куда передавать управление. Чтобы не разбираться с этим хаосом, стандарт просто вызывает std::terminate и завершает программу.

Подводный камень №2 — бросать по значению, ловить по ссылке. Если ловить по значению catch (std::exception e), произойдёт срезка (object slicing) — потеряется динамический тип и e.what() вернёт сообщение базового класса, а не реально брошенного производного.

throw std::runtime_error("boom");
// catch (std::exception e)          // ПЛОХО: slicing
// catch (const std::exception& e)   // ПРАВИЛЬНО

Аналогия: представьте, что вы ловите мяч. Если вы берёте его копию (по значению), вы теряете информацию о том, что это был, например, футбольный мяч с автографом, а не обычный теннисный. По ссылке же вы смотрите на оригинал и видите его реальный тип со всеми деталями.

noexcept — не только документация: компилятор может оптимизировать вызов (например, отказаться от генерации таблиц раскрутки в noexcept-функциях), а std::vector использует это свойство, чтобы решить, перемещать или копировать элементы (std::move_if_noexcept).

void safe() noexcept;                        // обещание не бросать
void risky() noexcept(false);                // явно разрешаем бросать
static_assert(noexcept(safe()));
// Внутри noexcept-функции любой бросок → std::terminate

На собеседовании спросят. «Почему деструкторы неявно noexcept?» — потому что они вызываются при раскрутке стека; если деструктор бросит в этот момент, новое исключение возникнет до обработки старого, и программа аварийно завершится (std::terminate). «Что делает noexcept(false)?» — разрешает бросать, но тогда такой объект опасен в контексте раскрутки. Дополнительно могут спросить: «Зачем noexcept swap-функциям?» — чтобы std::vector мог безопасно перемещать элементы при реаллокации; без noexcept он выберет копирование, что медленнее. Или: «Что такое std::move_if_noexcept?» — утилита, которая возвращает std::move(x), если перемещение у x помечено noexcept, иначе возвращает копию — чтобы сохранить strong guarantee.

Когда использовать noexcept. Помечайте перемещающие операции (иначе контейнеры будут копировать), деструкторы, swap и простые геттеры. Не помечайте функции, которые могут законно бросить, — ложное обещание приведёт к std::terminate вместо нормальной обработки ошибки.

Практическое правило: если вы пишете функцию, которая делает что-то «очень простое» (возвращает поле, меняет одно значение, освобождает ресурс), и вы уверены, что ни один из вызываемых методов не может бросить — помечайте noexcept. Сомневаетесь — не помечайте, безопаснее. Ложный noexcept страшнее, чем его отсутствие: он превращает любую ошибку в крэш программы.

Частые ошибки с исключениями.

• Ловить по значению. catch (std::exception e) срезает динамический тип — только const&. Теряется what() производного класса и любая специфичная информация.
• Бросать из деструктора. Деструктор неявно noexcept; бросок при раскрутке → std::terminate. Если нужно сообщить об ошибке в деструкторе — пишите в лог, но не бросайте.
• Глотать исключение молча. Пустой catch (...) {} прячет ошибку; минимум — залогировать. Иначе вы неделями ищете «куда делись данные».
• Ловить всё подряд в catch (...). Теряется информация о типе и сообщение. Используйте только как «сетку безопасности» в самом конце.
• Исключение как управляющий поток. Бросать на каждый найденный элемент — медленно; исключения — для исключительных ситуаций. Раскрутка стека дорогая, не используйте её вместо if.
• Не помечать move noexcept. vector начнёт копировать вместо перемещать. Это не ошибка с точки зрения корректности, но серьёзный performance regression.

Как выбирать между исключениями и кодом ошибки. Исключения — когда ошибка «не должна» случаться в нормальном потоке и её нельзя обработать на месте (нет файла, нет памяти). Код ошибки / expected — когда ошибка ожидаема и является частью логики (пользователь ввёл не число, элемент не найден).

Простое правило: «Это баг или нормальный случай?» Если баг — бросайте исключение, починка в коде. Если нормальный случай — возвращайте код ошибки, обрабатывайте на месте. Исключения стоят дорого (раскрутка стека, поиск catch), поэтому злоупотреблять ими для обычной логики — плохая идея. Дополнительно: в критичных к latency участках (hot loops, real-time) предпочитайте коды ошибок, потому что предсказать время обработки исключения нельзя.

Шаблоны и метапрограммирование

Шаблон (template) — это «чертёж» для генерации кода: сам по себе он не исполняется, а описывает, как из типов и значений-аргументов «выпечь» конкретную функцию, класс или переменную. Шаблоны позволяют писать код, параметризованный типами и значениями. Компилятор инстанцирует конкретную версию для каждого набора аргументов — это называется мономорфизацией (от греч. «одна форма»): из одного шаблона получается множество конкретных функций/классов, каждая под свой тип. Простыми словами, шаблон — это не готовый код, а форма для отливки: max_of<int> и max_of<double> — две разные функции, «отлитые» по одной форме в момент компиляции. Отсюда и скорость (нет накладных расходов рантайма — всё решено на этапе компиляции, как машинный код «зашит» в бинарник), и цена (код размножается в бинарнике, время компиляции растёт, отлаживать тяжелее — вы видите не свой шаблон, а его развёрнутую копию). Именно поэтому шаблоны иногда называют «бесплатным полиморфизмом с оплатой при компиляции».

#include <iostream>
#include <type_traits>

template <typename T>
T max_of(T a, T b) {                    // параметр-тип
    return (a < b) ? b : a;
}

template <typename T, int N>
struct Array {                          // параметр-значение (non-type)
    T data[N]{};
    constexpr int size() const { return N; }
};

template <typename T>
constexpr T pi = T{3.14159265358979323846};   // шаблонная переменная (C++14)

template <typename... Args>
auto sum(Args... args) {                // variadic template
    return (args + ... + 0);            // fold expression (C++17)
}

int main() {
    std::cout << max_of(3, 7) << '\n';              // T = int
    std::cout << max_of(2.5, 1.5) << '\n';          // T = double
    Array<int, 5> arr;
    std::cout << arr.size() << ' ' << sum(1, 2, 3, 4) << '\n';
    return 0;
}

Что это значит на практике. Параметр-тип (typename T) — самый частый: подставляется любой тип — хоть int, хоть ваш собственный класс. Именно так работает std::vector<T>. Параметр-значение (int N) позволяет задать размер ещё на этапе компиляции, как в std::array<T, N>: размер становится частью типа, поэтому компилятор может проверить выход за границы и аллоцировать массив на стеке без new. Пакет параметров (typename... Ts) принимает переменное число типов — так устроены std::tuple, std::variant, и «вариадические» обёртки вокруг printf-подобных функций. if constexpr компилирует только выбранную ветку, поэтому код в отброшенной может быть даже некорректным для данного типа (например, обращаться к полю, которого нет) — компилятор его не увидит и ошибки не будет.

Типичная ошибка новичка. Путать «параметр шаблона» и «аргумент шаблона». В template <typename T> — T это параметр (формальное имя). В max_of<int> — int это аргумент (конкретное значение, подставляемое вместо T). Точно как в функциях: void f(int x) — параметр, f(5) — аргумент.

Специализация позволяет задать особую реализацию для конкретного типа — как исключение из общего правила: «по умолчанию делай так, а вот для int — иначе»:

template <typename T>
struct TypeName { static constexpr const char* value = "unknown"; };

template <>
struct TypeName<int> { static constexpr const char* value = "int"; };

template <typename T>
struct TypeName<T*> { static constexpr const char* value = "pointer"; };   // частичная

Полная vs частичная специализация. Полная (template <> struct TypeName<int>) переопределяет шаблон для одного конкретного типа. Частичная (template <typename T> struct TypeName<T*>) — для семейства типов (всех указателей). Для функций полная специализация запрещена — используйте перегрузку.

if constexpr отбрасывает невыбранную ветку до инстанцирования — так пишут код, который не должен компилироваться для части типов. Это чистая альтернатива рантайм-веткам: платите нулевые издержки в рантайме, зато компилятор проверяет только нужную ветку:

template <typename T>
void describe(const T& value) {
    if constexpr (std::is_integral_v<T>) {
        std::cout << "целое: " << value << '\n';
    } else if constexpr (std::is_floating_point_v<T>) {
        std::cout << "вещественное: " << value << '\n';
    } else {
        std::cout << "другое\n";
    }
}

Почему тут if, а не обычный if? Обычный if проверяется в рантайме, но обе ветки должны быть корректным кодом для типа T — иначе ошибка компиляции. if constexpr проверяет условие в момент компиляции и выкидывает ложную ветку до того, как компилятор начнёт разбирать её синтаксис и семантику. Поэтому в «мёртвой» ветке можно писать value.size(), даже если у int нет метода size() — компилятор эту ветку просто не увидит.

SFINAE и void_t — старая (но всё ещё встречающаяся) техника ограничения перегрузок. Название — аббревиатура от Substitution Failure Is Not An Error: «если подстановка не удалась — это не ошибка, а повод отбросить перегрузку». std::void_t<T> превращается в void, если все типы в нём валидны, иначе подстановка проваливается, и перегрузка отбрасывается. Используется как «детектор» наличия у типа нужного свойства:

#include <type_traits>
#include <iterator>

template <typename T, typename = std::void_t<>>    // базовый случай
struct has_iterator : std::false_type {};

template <typename T>
struct has_iterator<T, std::void_t<typename T::iterator>> : std::true_type {};

Разбор has_iterator. Базовый шаблон отвечает «нет» (false_type). Частичная специализация с void_t<typename T::iterator> подходит только для типов, у которых есть T::iterator; для остальных подстановка проваливается по правилу SFINAE, и специализация просто отбрасывается — ошибки нет. Итог: мы спрашиваем у компилятора, есть ли у типа итератор. Это основа старых библиотек (Boost, C++11/14) до появления concepts. Аналогия из жизни: вы проверяете, умеет ли человек плавать, спрашивая у страховой компании — если тип «плавучий», она выдаст полис; иначе — откажет без скандала.

Частая ловушка. SFINAE работает только в «непосредственном контексте» подстановки: если ошибка возникает в теле инстанцированной функции, это уже жёсткая ошибка компиляции, а не «мягкое» отбрасывание перегрузки. Именно поэтому SFINAE-код такой громоздкий и почему в C++20 от него отказались в пользу concepts. Практический совет: если видите enable_if в современном коде — это либо легаси, либо случай, где concepts неудобны; в новом коде предпочитайте requires.

C++20: concepts и requires заменяют громоздкий SFINAE читаемыми ограничениями. Концепт — именованное требование к типу; перегрузки отбираются компилятором до тела функции. Если шаблон — это «форма для отливки», то концепт — это «чертёж допусков»: какими свойствами должна обладать заготовка, чтобы её вообще взяли в обработку.

#include <concepts>
#include <iostream>

template <typename T>
concept Addable = requires(T a, T b) {              // требует валидности выражений
    { a + b } -> std::same_as<T>;
};

template <Addable T>
T add(T a, T b) { return a + b; }                   // участвует в перегрузке только для Addable

// Эквивалентно: template <typename T> requires Addable<T> T add(T a, T b);

template <std::integral T>                          // стандартный концепт из <concepts>
T twice(T x) { return x * 2; }

int main() {
    std::cout << add(1, 2) << ' ' << twice(21) << '\n';
    // add(std::string{"a"}, std::string{"b"});     // тоже OK: std::string + std::string
    // add(1, 2.5);                                 // ошибка: разные типы
    return 0;
}

Анатомия concept Addable. Ключевое слово requires(...) описывает набор требований-выражений: внутри скобок стоят валидные C++-выражения от параметров концепта. Запись { a + b } -> std::same_as<T>; означает: «выражение a + b должно быть корректным И его тип должен совпадать с T». Если тип не удовлетворяет хотя бы одному требованию — он «не Addable», и шаблон с template <Addable T> для него не инстанцируется, компилятор ищет другую перегрузку.

Практическая подсказка. В C++20 чаще используют не собственные концепты, а готовые из <concepts>: std::integral, std::floating_point, std::same_as, std::convertible_to, std::ranges::range. Это сильно сокращает шаблонный код и делает сообщения об ошибках понятными — компилятор укажет, какое именно требование нарушено. Когда использовать шаблоны, а когда нет. Шаблоны в C++ — это механизм, позволяющий написать алгоритм или структуру данных один раз и использовать её с разными типами (int, double, std::string, пользовательскими классами), сохраняя при этом максимальную производительность.

Простая аналогия: представьте кондитерскую форму для печенья. Сама форма — это шаблон, а тесто (шоколадное, ореховое, миндальное) — это конкретный тип. Из одной формы получается печенье разных «вкусов», но логика вырезания одна и та же. Так и шаблон: один код → множество конкретных реализаций под каждый тип.

Шаблоны нужны, когда один и тот же алгоритм должен работать с разными типами, а потери на виртуальных вызовах недопустимы: контейнеры, алгоритмы, математические типы, обёртки.

Почему виртуальные вызовы — это «потери»? Виртуальная функция требует обращения к таблице виртуальных методов (vtable) во время выполнения программы — это как спрашивать дорогу у прохожих на каждом перекрёстке. Шаблон же генерирует отдельную «копию» кода под каждый тип ещё на этапе компиляции, и компилятор может спокойно заинлайнить вызовы, применить агрессивные оптимизации. Поэтому std::vector<int>::push_back в горячем цикле работает заметно быстрее, чем эквивалентный вызов через виртуальный интерфейс.

Не пишите шаблон «на будущее» для одного типа — это усложнит компиляцию ошибок и увеличит время сборки.

Почему это плохая практика? Даже если сейчас шаблон инстанцируется под единственный тип, компилятор всё равно будет разбирать шаблонный код в «двухпроходном» режиме, проверять зависимые имена (dependent names), и при любой ошибке вы получите развёрнутые, тяжёлые для чтения сообщения. Другие разработчики будут вынуждены разбираться в шаблонной механике без реальной выгоды. Шаблон должен быть следствием повторяющегося паттерна, а не преждевременным обобщением.

Помните о цене: код инстанцируется для каждого типа (растёт бинарник), а сообщения об ошибках становятся длинными.

Типичная ошибка новичков: использование шаблонов ради «общего вида» в простых функциях, которые используются один-два раза.

• Плохо: template <typename T> T addOne(T x) ради гипотетической универсальности.
• Хорошо: int addOne(int x), пока нет реальной необходимости в обобщении.

Практическая подсказка: правило «трёх вызовов» — если вы используете одинаковую логику для трёх и более разных типов, шаблон оправдан. Если меньше — лучше явный код или перегрузка функций. Ещё один маркер: если в API библиотеки тип упоминается в каждом методе (MyClass<T>::method(), MyClass<T>::field), значит, перед вами кандидат на шаблон.

Подводный камень — ошибки шаблонов огромны. Это одна из самых известных «болей» C++-разработчиков, и причина — в самом механизме работы шаблонов.

Почему ошибки такие длинные? Когда компилятор встречает вызов шаблонной функции с конкретным типом, он должен мысленно «подставить» этот тип везде, где в шаблоне стоит параметр T. Если где-то в процессе возникает ошибка (например, T не поддерживает оператор +), компилятор печатает всю цепочку инстанцирования — то есть весь путь от точки вызова до проблемного места в шаблоне. Это как если бы вы читали не одно сообщение об ошибке, а целый детективный сюжет, где каждый «персонаж» — это один уровень вложенности шаблона в шаблон.

Простая аналогия: представьте, что вы просите друга передать вам книгу через цепочку из 10 человек. Если последний человек не может найти нужную книгу, вам придёт сообщение от каждого из 10: «Я попросил следующего...», «Я передал дальше...», «Я получил запрос...». Чтобы найти суть проблемы, нужно пролистать всё до самого последнего сообщения.

Компилятор печатает всю цепочку инстанцирования. Средства: concepts вместо SFINAE, static_assert с понятным сообщением, template <typename T> using ... для сокращения, clang с -fno-show-template-tree не нужен — читайте снизу вверх.

Разбор каждого средства:

• Concepts (C++20) — это способ явно сказать компилятору «T должен поддерживать оператор +» или «T должен быть целочисленным». Если тип не подходит, ошибка возникает сразу на этапе проверки концепта, а не глубоко внутри шаблона после раскрытия всех типов.
• static_assert с понятным сообщением — это ручной «контроль качества»: «стоп, если условие неверно, и вот почему». Например: static_assert(std::is_integral_v<T>, "T должен быть целочисленным типом");. Так вы получаете ошибку ровно там, где хотите, с тем текстом, который сами написали.
• template <typename T> using ... — это alias-шаблоны, которые сокращают длинные typename-выражения и убирают часть «шума» из сообщений об ошибках. Вместо typename std::vector<T>::iterator можно написать using Iter = typename std::vector<T>::iterator;.

Практическая подсказка: флаг Clang -fno-show-template-tree действительно существует и «расплющивает» дерево инстанцирования, но часто это делает сообщение ещё менее читаемым — теряется визуальная структура «кто от кого зависит». Лучше освоить технику чтения «снизу вверх», о которой пойдёт речь ниже.

Как читать ошибку шаблона. Это ключевой навык для любого C++-разработчика, работающего с обобщённым кодом.

Аналогия из жизни: представьте, что вы заблудились в большом торговом центре и спрашиваете дорогу. Вам отвечают длинно: «Сначала пройдите мимо магазина А, потом через переход к Б, потом поднимитесь на второй этаж к В, потом поверните направо...» — это всё «путь». А реальная проблема может быть простой: «нужный магазин сегодня закрыт на переучёт». Так вот, верх сообщения об ошибке — это путь инстанцирования, а низ — суть проблемы.

Читайте снизу вверх: последняя строка обычно и есть настоящая причина, а всё, что выше, — «путь» инстанцирования (кто кого вызвал).

Пошаговый алгоритм:

1. Прокрутите сообщение об ошибке до самого конца — иногда это сотни строк.
2. Найдите строку, начинающуюся с error: — это и есть настоящая причина.
3. Прочитайте её внимательно: часто там написано что-то вроде «no match for operator+» или «invalid initialization of reference».
4. Посмотрите на строку выше — там обычно указан файл и строка внутри шаблона, где произошла ошибка.
5. Если не понимаете, кто вызвал этот шаблон с неподходящим типом, — читайте вверх по цепочке, пока не встретите свой код.

Первое, что стоит сделать, — найти в сообщении ваш файл и строку с вызовом.

Почему именно так? Ошибки внутри системных заголовков (например, <vector>, <algorithm>, <type_traits>) — это почти всегда следствие неправильного использования шаблона в вашем коде. Если вы нашли свою строку с вызовом, значит, проблема в типе, который вы передали, а не в самом стандартном шаблоне. Сstd::vector не сломан — сломан ваш способ его использовать.

Практическая подсказка: в IDE (CLion, Visual Studio, VS Code с C++-плагинами) обычно есть специальное окно «свёрнутых» ошибок, где каждая инстанциация представлена одной строкой с возможностью раскрыть её по клику. Используйте его — это сильно ускоряет навигацию по длинным сообщениям.

Типичная ошибка: пытаться читать ошибку сверху вниз и паниковать от объёма. Реальная информация почти всегда в конце. Ещё одна частая ошибка — путать «путь» (instantiation stack) с самой ошибкой и пытаться «починить» системный заголовок, который ни в чём не виноват.

На собеседовании спросят. Это одни из самых частых вопросов, которые проверяют глубину понимания шаблонов в современном C++.

«Зачем concepts, если есть SFINAE?» — читаемость: template <Addable T> понятнее, чем enable_if_t<...>; к тому же concepts дают осмысленные сообщения об ошибках и участвуют в разрешении перегрузок понятным образом.

Расширенный ответ для собеседования — четыре ключевых преимущества concepts:

1. Читаемость кода и самодокументирование. Concepts — это, по сути, документирование намерений прямо в сигнатуре. Когда вы пишете template <Addable T> T sum(T a, T b), любой, кто читает код, мгновенно понимает: «T — это тип, который можно складывать». SFINAE же без комментариев выглядит как магия: template <typename T, typename = std::enable_if_t<std::is_arithmetic_v<T>>> — нужно вчитаться, чтобы понять ограничение.

2. Качество сообщений об ошибках. С SFINAE, если условие не выполнилось, вы часто получаете загадочное «no matching function for call to ...» — без указания, почему именно не подошёл тип. С concepts компилятор пишет прямо: «the associated constraints are not satisfied» или даже указывает, какой именно концепт нарушен и какое выражение в нём не компилируется.

3. Полноценное участие в разрешении перегрузок. Concepts — это полноправные «предикаты», которые участвуют в overload resolution на равных с другими факторами. SFINAE через enable_if — это, по сути, хак, и его поведение в перегрузках иногда неочевидно: при частичной специализации и приоритетах шаблонов можно получить сюрпризы.

4. Композиция и повторное использование. Concepts можно комбинировать через && и ||: template <Integral && Addable T>. Можно делать «концепт-концепта»: template <typename T> concept Numeric = Integral<T> || FloatingPoint<T>;. С SFINAE то же самое превращается в арифметику с вложенными enable_if_t, которую сложно читать и поддерживать.

Другие частые вопросы на собеседовании по шаблонам:

• «Чем typename отличается от class в параметре шаблона?» — исторически ничем, оба слова эквивалентны, но typename предпочтительнее, потому что явно говорит: параметр может быть любым типом (включая вложенные typedef в шаблоне).
• «Что такое специализация шаблона?» — это способ написать отдельную реализацию для конкретного типа (например, оптимизированную версию Stack<bool> с битовой упаковкой).
• «Что такое variadic templates?» — шаблоны с переменным числом аргументов: template <typename... Args>. Используются, например, в std::make_tuple или std::function.
• «Что такое template metaprogramming?» — это выполнение вычислений на этапе компиляции через рекурсивную специализацию шаблонов (раньше — единственный способ, сейчас часто заменяется constexpr-функциями).

Практическая подсказка для ответа: не просто перечисляйте преимущества concepts, а покажите конкретный пример кода: «вот так SFINAE выглядит запутанно, а вот так с concepts — прозрачно и понятно даже junior-разработчику». Это демонстрирует практический опыт, а не заученную теорию.

STL: контейнеры, итераторы, алгоритмы

STL состоит из трёх «китов»: контейнеров (хранят данные), итераторов (дают доступ к элементам контейнера единообразно) и алгоритмов (обрабатывают данные через итераторы). Главная идея — алгоритмы ничего не знают о контейнерах: они работают только с итераторами. Такое разделение даёт комбинаторику: один std::sort работает и с vector, и с deque, и с обычным C-массивом — потому что все они предоставляют итераторы. Это и есть полиморфизм времени компиляции: вместо виртуальных функций — шаблоны и абстракция «указатель-в-контейнер».

Что такое итератор. Это обобщённый «указатель на элемент» — объект, который умеет *it (разыменовать), ++it (перейти к следующему) и it != other (сравнить с другим). У любого контейнера есть begin() (указывает на первый элемент) и end() (указывает на условный элемент за последним — полуинтервал [begin, end)). Аналогия из жизни: итератор — закладка в книге; алгоритм листает страницы, не зная, бумажная это книга или электронная. Ещё точнее — это как палец читающего человека: он «сейчас на этом слове», может сдвинуться вправо и в какой-то момент «соскочить» за конец текста — там читать уже нечего. Именно из-за полуинтервала циклы пишут it != end(), а не it <= end(): end() — это «место сразу после последнего», туда ходить нельзя, но сравнивать — можно.

Категории итераторов (от слабого к сильному): input (только чтение, одно прохождение — как чтение файла), output (только запись, одно прохождение), forward (можно ходить вперёд много раз — forward_list), bidirectional (можно и вперёд, и назад — list, map, set), random access (можно прыгнуть на it + n за O(1) — vector, deque, обычный указатель). Алгоритм предъявляет к итератору минимально нужную категорию: std::find хватит input, а std::sort требует random access — поэтому sort для list не работает (и не нужен, ведь у list есть свой list::sort).

Контейнеры и сложность операций

* Амортизированно; при плохой хеш-функции деградирует до O(n).

Как читать таблицу. Колонка Доступ отвечает на вопрос «сколько стоит добраться до i-го элемента?». Поиск — «сколько стоит найти элемент по значению/ключу?». Вставка/удаление — «сколько стоит добавить/убрать элемент туда, куда можно у данного контейнера». Прочерки означают, что операция либо невозможна (нет [] у list), либо бессмысленна для адаптера (stack — обёртка, к ней нельзя обратиться «сбоку»).

Что значит O(...) на практике. O(1) — «не зависит от размера»: и для 10 элементов, и для 10 миллионов время одно и то же (с точностью до константы). O(log n) — «очень мало шагов»: для n = 1 000 000 это всего ~20 шагов (потому что log₂(10⁶) ≈ 20). O(n) — «просматриваем всё»: время растёт линейно с размером. O(n log n) — «сортировка»: чуть больше, чем линейно. Для vector поиск — O(n), потому что данные лежат подряд в памяти и их приходится перебирать один за другим; для map — O(log n), потому что это сбалансированное дерево и на каждом шаге мы отбрасываем половину; для unordered_map — O(1) в среднем (идеальная хеш-таблица — массив, где по хешу сразу прыгаем в нужную ячейку), но в худшем случае (все ключи попали в один бакет — «хеш-коллизия») — снова O(n). «Амортизированно» для push_back в vector означает: обычно O(1), но раз в N вставок происходит перевыделение буфера за O(n) (вектор удваивает ёмкость, копирует элементы, освобождает старый буфер), и в среднем на одну вставку выходит константа. Аналогия — лотерея: иногда больно, но «в среднем по больнице» — дёшево.

Какую сложность выбирать. Если важен быстрый доступ по индексу — vector; если частый поиск по ключу — unordered_map (быстрее в среднем, но платите за хеширование и память) или map (если нужен порядок обхода и предсказуемое время). list берут редко: выигрыш на вставке в середину (O(1) против O(n) у vector) часто перекрывается плохой локальностью памяти — элементы list разбросаны по куче, процессор постоянно промахивается мимо кеша, и реальное время оказывается хуже, чем у «более медленного» алгоритма на vector.

Типичные ошибки при чтении сложности.

1. Путать среднее и худшее: у unordered_map написано O(1), но без reserve() и с плохим хешем в продакшене будет O(n) — и вы это увидите только под нагрузкой.
2. Путать вставку по итератору (O(1)) и вставку по значению (O(n) — сначала найти, куда). list::push_back — O(1), а list::insert(find(...)) — уже O(n).
3. Забывать про «константу в O»: O(1) у unordered_map на деле дороже, чем O(1) у vector — там хеш, там аллокация узла, там указатель. Поэтому для маленьких данных vector побеждает даже unordered_map.

Как выбрать контейнер за 30 секунд.

1. Нужен индекс [i] и быстрый обход — std::vector (по умолчанию берите его).
2. Нужны вставки/удаления с обоих концов — std::deque.
3. Нужен поиск по ключу без порядка — std::unordered_map / std::unordered_set.
4. Нужен поиск по ключу и упорядоченный обход — std::map / std::set.
5. Нужен стек/очередь/приоритет — std::stack / std::queue / std::priority_queue.
6. Нужен фиксированный размер на стеке — std::array.
7. Нужны вставки в середину при огромных размерах и стабильные итераторы — std::list (редко).

Когда использовать, а когда нет. Начинайте с vector, даже если кажется, что «нужен список»: на современных процессорах непрерывная память настолько важнее алгоритмической сложности, что vector часто обгоняет list даже на вставках. Измеряйте, а не угадывайте — правило «premature optimization is the root of all evil» здесь работает в обе стороны: не оптимизируйте вслепую, но и не отказывайтесь от измерений, когда разница в 10× уже маячит на горизонте.

Подводный камень хеш-таблиц. unordered_map хорош, пока ваши ключи — простые типы с готовым std::hash (int, std::string). Если ключ — структура, придётся писать operator== и специализацию std::hash, иначе код не скомпилируется. Ещё тонкость: при rehash все итераторы unordered_map инвалидируются (в отличие от ссылок, которые остаются живыми) — учитывайте это, если храните итераторы надолго.

#include <algorithm>
#include <iostream>
#include <map>
#include <unordered_map>
#include <vector>

int main() {
    std::vector<int> v{5, 2, 8, 1, 9};

    std::sort(v.begin(), v.end());                       // 1 2 5 8 9
    auto it = std::lower_bound(v.begin(), v.end(), 5);   // первый >= 5 (требует сортировки)
    v.erase(std::remove_if(v.begin(), v.end(), [](int x) { return x % 2 == 0; }), v.end());

    std::map<std::string, int> m{{"b", 2}, {"a", 1}};    // упорядочен по ключу
    m["c"] = 3;                                          // вставка через operator[]
    m.insert_or_assign("a", 10);                         // не создаёт значение по умолчанию

    if (auto found = m.find("b"); found != m.end()) {    // C++17: init-statement в if
        std::cout << found->first << '=' << found->second << '\n';
    }

    std::unordered_map<int, std::string> cache;
    cache.reserve(1000);                                 // заранее резервируем бакеты — меньше рехешей
    cache.emplace(1, "one");
    return 0;
}

Инвалидация итераторов — главная ловушка STL

Операции, меняющие размер контейнера, могут сделать итераторы и ссылки невалидными. Использование невалидного итератора — UB (undefined behavior, неопределённое поведение): программа имеет право сделать что угодно — упасть, выдать неправильный ответ, испортить память. Компилятор не обязан вас предупреждать.

Почему итераторы «ломаются». vector хранит элементы в непрерывном буфере (как обычный массив в куче). Когда при push_back места не хватает, контейнер выделяет новый буфер большего размера (обычно ×2), переносит туда элементы и освобождает старый. Старые итераторы/ссылки продолжают «помнить» адрес в уже освобождённой памяти — это висячие указатели (dangling pointers). erase же сдвигает элементы влево, заполняя «дыру», поэтому итератор на удалённый элемент и все последующие итераторы указывают уже не туда (как места в строю, когда одного человека выдернули — остальные шагнули влево). У узловых контейнеров (list, map) элементы живут в отдельных узлах, разбросанных по куче, и при вставке/удалении других элементов не переезжают — поэтому там инвалидируется только итератор/указатель на удалённый узел. Аналогия: vector — это шкаф с плотно стоящими книгами: чтобы вставить одну, нужно подвинуть соседей (или переставить весь шкаф). list — это сумка с карточками: каждая карточка лежит, где лежала, и вставка новой ничего не сдвигает.

Практическое правило безопасности. Прежде чем что-то делать с контейнером в цикле — сверьтесь с таблицей ниже или с документацией. Если операция инвалидирует итераторы — заведите новый итератор сразу после операции. Для vector самый надёжный путь — идиома erase-remove или std::erase_if (C++20), а вручную — брать it = container.erase(it).

#include <vector>

int main() {
    std::vector<int> v{1, 2, 3, 4};

    // ПЛОХО: erase сдвигает элементы, текущий итератор invalided
    for (auto it = v.begin(); it != v.end(); ++it) {
        if (*it % 2 == 0) v.erase(it);      // UB: it указывает на удалённый элемент
    }

    // ПРАВИЛЬНО (C++11+): erase возвращает следующий валидный итератор
    for (auto it = v.begin(); it != v.end();) {
        if (*it % 2 == 0) it = v.erase(it);
        else ++it;
    }

    // ПРАВИЛЬНО (C++20): std::erase_if
    // std::erase_if(v, [](int x) { return x % 2 == 0; });

    // Ловушка push_back: итераторы инвалидируются при перевыделении буфера
    auto first = v.begin();
    for (int i = 0; i < 100; ++i) v.push_back(i);
    // first — невалиден, если буфер перевыделялся
    return 0;
}

Частые сценарии инвалидации, о которых забывают.

1. reserve у vector — не инвалидирует ничего (только перевыделяет буфер, если новый размер больше), а вот shrink_to_fit — может инвалидировать всё.
2. clear — для vector инвалидирует всё (буфер остаётся, но элементов нет); для list/map — инвалидирует всё (узлы освобождаются).
3. Передача контейнера в функцию, которая внутри делает push_back, — классическая ошибка «безопасно в нашем файле, падает в соседнем». Сохраняйте итератор снаружи — и помните: если функция может расти, итератор может умереть.
4. Цикл с push_back и заранее сохранённым begin() — почти гарантированный UB: после первой же вставки, если буфер перевыделился, ваш begin() указывает в освобождённую память.

Лайфхак. Если нужен «вектор, в который можно безопасно добавлять, не думая об итераторах» — берите std::deque (вставки с конца инвалидируют итераторы, но не ссылки). Если нужны стабильные итераторы при любых вставках — std::list. Но помните про кеш: за стабильность итераторов вы платите скоростью на обходе. Что это значит на практике. «Все итераторы и ссылки» для vector при росте — самая частая причина висячих ссылок. Висячая ссылка (dangling reference/pointer) — это ссылка или указатель, которые указывают туда, где объекта уже нет: память либо переиспользована, либо освобождена. Чтение или запись через такую ссылку — неопределённое поведение (UB): сегодня программа «работает», завтра падает, послезавтра выдаёт неверный ответ.

Аналогия из жизни. Представьте, что вы записали домашний адрес друга в блокнот, а друг переехал. Блокнот по-прежнему содержит старый адрес — заглянув туда, вы попадёте либо к чужим людям, либо в пустую квартиру. Именно так работают ссылки в C++: они не следят за жизнью объекта — за этим следите вы сами.

Правила гигиены: (1) не храните итераторы и ссылки на элементы vector, если он может вырасти; (2) в цикле удаления используйте возвращаемый erase, а не ++it; (3) если размер известен — вызовите reserve() заранее, тогда перевыделений не будет вовсе.

Пояснение к каждому пункту:

• (1) Не храните итераторы/ссылки на время роста. Если вам нужно обратиться к элементу после потенциальной модификации контейнера — пересчитайте индекс или получите ссылку заново: int& r = v[i];. Это дёшево и безопасно.
• (2) erase сам двигает итератор. После it = vec.erase(it) итератор указывает на следующий элемент (или на end()). Если делать ++it вручную, вы пропустите элемент, идущий сразу после удалённого, — классическая ошибка.
• (3) reserve(n) говорит: «выдели место под n элементов сразу». Это устраняет перевыделения в будущем, пока вы не превысите n. Указание точного размера превращает push_back из потенциально дорогой операции в гарантированно дешёвую (амортизированная сложность остаётся O(1), но без скачков).

Ссылки на элементы vector инвалидируются при росте буфера — распространённый источник висячих ссылок:

std::vector<int> v;
v.reserve(1);
const int& r = v[0];          // ссылка на элемент
v.push_back(42);              // перевыделение → r висит!

Почему так. Внутри vector — обычный динамический массив. Когда места не хватает, он выделяет новый буфер (обычно в 1.5–2 раза больше), копирует/перемещает элементы и освобождает старый. Все старые итераторы и ссылки указывают в освобождённую память — отсюда и «висячесть». Обойти это нельзя: перевыделение обязано перенести данные, и старые адреса теряют смысл.

Лямбда-выражения и захваты

Лямбда-выражение (lambda) — это способ определить маленькую функцию прямо в том месте, где она нужна: без отдельного объявления, без имени, с возможностью захватить переменные из окружения. Удобно для алгоритмов, колбэков и коротких предикатов. Компилятор «под капотом» превращает каждую лямбду в безымянный класс с оператором operator(), а список захвата (в квадратных скобках [ ]) задаёт поля этого класса — копии или ссылки на внешние переменные.

Аналогия из жизни. Лямбда — это курьер, которому вы в момент отправки передаёте «заметки» (захваты) о том, что ему понадобится во время работы. Захват по значению — выдать ему ксерокопию документа, по ссылке — разрешить подсматривать в оригинал. Если оригинал потом уничтожить — курьер окажется с пустыми руками.

#include <algorithm>
#include <iostream>
#include <vector>

int main() {
    int threshold = 3;
    std::vector<int> v{1, 5, 2, 8};

    // [threshold] — захват по значению: копия переменной внутрь лямбды
    auto by_value = [threshold](int x) { return x > threshold; };

    // [&threshold] — захват по ссылке: лямбда видит изменения снаружи
    auto by_ref = [&threshold](int x) { return x > threshold; };

    // [=] и [&] — захватить всё по значению / по ссылке (осторожно!)
    // [this] — захватить указатель на текущий объект (в методах класса)
    // [x = threshold * 2] — инициализирующий захват (C++14): вычисляем при создании

    int count = 0;
    std::for_each(v.begin(), v.end(), [&count](int) { ++count; });   // счётчик снаружи
    std::cout << count << ' ' << by_value(4) << by_ref(4) << '\n';   // 4 1 1
    return 0;
}