1. Зачем C++ нужен noexcept
Если вы привыкли к обычному return, то «выход через исключение» звучит как альтернативная реальность. И в некотором смысле так и есть: это путь, при котором функция не возвращает управление обычным способом, а выполнение «прорывается» наружу. Сегодня мы не изучаем синтаксис try/catch и не учимся «ловить» исключения — нам достаточно модели: иногда внутри функции может произойти событие, из‑за которого управление покинет функцию не через return.
noexcept — это способ сказать компилятору и всем читателям кода: «вот эта функция никогда не должна завершаться таким аварийным выходом». Это не комментарий и не просьба. Это обещание уровня «контракт». Более того, в современных версиях C++ спецификация исключений является частью типа функции (то есть влияет на совместимость сигнатур и перегрузку).
И тут появляется главный смысл: noexcept помогает делать код предсказуемым. Когда вы проектируете тип с перемещением, вы хотите, чтобы перемещение было «железобетонным»: перенос указателя, обнуление источника — и всё. Без сюрпризов.
Синтаксис noexcept
Снаружи noexcept выглядит почти слишком просто — и это хорошо. Контракт должен читаться мгновенно.
Минимальная форма:
#include <iostream>
void print_hello() noexcept {
std::cout << "Hello!\n"; // Hello!
}
Здесь noexcept стоит в объявлении функции и означает: эта функция не должна завершаться выходом через исключение. В рамках нашей упрощённой модели сегодня можно думать так: если внутри print_hello() произойдёт нечто, что попробует «вылететь наружу как исключение», то программа не продолжит работу «как обычно».
Ещё важный момент: noexcept — это не «ускоритель». Да, он может влиять на оптимизации, но в первую очередь это семантика. Контракт. Обещание.
Иногда вы увидите форму noexcept(true) или noexcept(false). Сейчас достаточно понимать идею: noexcept бывает условным, но в наших примерах мы будем использовать базовую форму noexcept, потому что она лучше всего подходит для move-операций ресурсного типа.
2. Что будет при нарушении noexcept
Представьте, что noexcept — это табличка «НЕ ВХОДИТЬ» на двери. Пока вы её уважаете — всё нормально. Но если вы всё-таки вошли, то дальше не «штраф», а «дверь за вами закроется и здание уйдёт в режим эвакуации».
Технически это выражается так: если исключение пытается покинуть noexcept‑функцию, вызывается std::terminate(), и программа аварийно завершает работу. Это не «может быть», это именно модель языка.
Для интуиции удобно нарисовать блок‑схему:
flowchart TD
A["Функция объявлена noexcept"] --> B["Внутри случилось событие, которое пытается выйти наружу как исключение"]
B --> C{"Исключение выходит за пределы noexcept-функции?"}
C -- "Да" --> D["std::terminate()"]
D --> E["Программа аварийно завершена"]
C -- "Нет" --> F["Работа продолжается обычным способом"]
Почему так жёстко? Потому что noexcept — это обещание, на которое могут опираться другие части программы и стандартная библиотека. Если бы нарушение noexcept «мягко» обрабатывалось, весь смысл контракта расплылся бы.
Поэтому важное правило новичка звучит так: никогда не ставьте noexcept «на всякий случай». Это не «пусть будет», это «я уверен, что наружу ничего не вылетит».
4. Почему noexcept важен для move-операций
На этом месте часто спрашивают: «Окей, контракт строгий. Но почему вокруг move столько разговоров про noexcept?» Причина очень практическая: перемещение часто используется внутри стандартных контейнеров, особенно когда контейнеру нужно «переселить» элементы в новое место.
Представьте std::vector<T>. Он хранит элементы в одном непрерывном блоке памяти. Иногда ему нужно увеличить capacity, выделить новый блок и перенести туда элементы. И вот тут встаёт вопрос: как переносить элементы — копированием или перемещением?
Если move‑конструктор типа T помечен noexcept, то для vector перемещение выглядит как «безопасная операция переселения». Если же move потенциально может «вылететь наружу», контейнер может предпочесть копирование (если копирование доступно). В стандартной библиотеке даже есть идея «перемещай, только если это не бросает» — её часто связывают с подходом move_if_noexcept (название можно запомнить как подсказку, но сейчас достаточно понять мотивацию).
Это не значит, что без noexcept всё сломается. Это значит, что тип становится менее дружелюбным к контейнерам и алгоритмам, которые хотят безопасно и эффективно «тасовать» элементы.
5. Пример: ресурсный Buffer и move-операции с noexcept
Посмотрим на noexcept на конкретном типе, который владеет ресурсом напрямую.
Пусть у нас есть Buffer — владелец динамического массива int. Это учебный пример, но он хорошо показывает механику владения:
#include <cstddef>
struct Buffer {
std::size_t size{};
int* data{nullptr};
explicit Buffer(std::size_t n) : size(n), data(new int[n]{}) {}
~Buffer() { delete[] data; }
};
Проблема уже знакомая: копирование по умолчанию сломает владение (скопирует адрес). Поэтому в прошлых лекциях дня мы добавили глубокую копию (копирующий конструктор и копирующее присваивание). А теперь добавим перемещение — и именно здесь noexcept обычно уместен.
Move-конструктор и noexcept
Здесь важно проговорить смысл: move‑конструктор — это операция, которая обычно делает очень простые действия: присвоить указатель и размер, обнулить источник. В таком коде мы обычно не выделяем память и не делаем «опасных» операций. Поэтому его удобно и логично объявить noexcept: мы действительно можем честно обещать, что «вылета наружу» не будет.
#include <cstddef>
struct Buffer {
std::size_t size{};
int* data{nullptr};
explicit Buffer(std::size_t n) : size(n), data(new int[n]{}) {}
~Buffer() { delete[] data; }
Buffer(Buffer&& other) noexcept : size(other.size), data(other.data) {
other.size = 0;
other.data = nullptr;
}
};
Обратите внимание на два «священных» действия: мы забрали ресурс и привели источник в пустое состояние. И это пустое состояние корректно переживёт деструктор (delete[] nullptr безопасен).
Move-присваивание и noexcept
Логика похожая, но появляется дополнительная ответственность: слева уже мог быть ресурс, его надо аккуратно освободить. Здесь тоже обычно нет причин «вылетать наружу», если вы не делаете ничего кроме delete[] и присваиваний.
#include <cstddef>
struct Buffer {
std::size_t size{};
int* data{nullptr};
explicit Buffer(std::size_t n) : size(n), data(new int[n]{}) {}
~Buffer() { delete[] data; }
Buffer(Buffer&& other) noexcept : size(other.size), data(other.data) {
other.size = 0;
other.data = nullptr;
}
Buffer& operator=(Buffer&& other) noexcept {
if (this == &other) return *this;
delete[] data;
size = other.size;
data = other.data;
other.size = 0;
other.data = nullptr;
return *this;
}
};
Маленькая «проверка здравого смысла»: если в move‑операциях вы вдруг пишете new, значит, вы почти наверняка делаете что-то не так. Move — это «перенос владения», а не «построение нового ресурса».
6. Как понять, можно ли писать noexcept
Новичкам хочется универсального рецепта: «Скажите, когда можно, а когда нельзя». Универсального на 100% нет. Но есть очень рабочая логика проверки, которую можно применять даже без уверенного знания try/catch.
Сначала задайте себе вопрос: «Может ли эта функция внутри себя сделать что-то, что потенциально приводит к попытке выйти наружу через исключение?» Типичные подозреваемые — выделение памяти, создание сложных объектов, операции ввода/вывода, «умные» контейнеры, которые внутри могут выделять память. Если ответ «да» или «не уверен» — не ставьте noexcept.
Если функция делает только простые и предсказуемые действия, вроде присваивания указателей, обмена целых чисел, обнуления полей, освобождения ресурса, то noexcept обычно уместен.
Удобно держать мини-таблицу:
| Операция | Часто уместен noexcept? | Почему |
|---|---|---|
| Move «перенос указателя + обнуление» | Да | Обычно нет выделений памяти |
| Деструктор, который просто освобождает ресурс | Да | Освобождение ресурса должно быть надёжным |
| Копирование с new и циклом копирования | Обычно нет | Выделение памяти может не получиться |
| Функция, которая пишет в std::cout | Обычно нет | I/O может быть настроен на исключения, да и контракт лучше не обещать «железо» |
noexcept — это часть интерфейса. Вы не просто говорите «внутри всё хорошо», вы говорите пользователю типа: «можно на меня рассчитывать». Поэтому лучше недообещать, чем переобещать.
Почему noexcept — это про доверие
В программировании «обещания» нужны не ради морали, а ради того, чтобы другие части системы могли принимать решения. И noexcept — именно такое обещание. Оно позволяет писать более простой и предсказуемый код вокруг вашей функции.
Например, если у вашего типа move‑операции noexcept, то перемещение можно использовать как базовый кирпич для безопасных операций перестановки. Даже если вы пока не используете это напрямую, стандартная библиотека может использовать.
Кроме того, noexcept дисциплинирует вас как автора. Если вы пометили move noexcept, у вас появляется внутренняя установка: «в move я не добавляю логики, которая может привести к проблемам». Это часто ведёт к более чистому дизайну: move остаётся «механическим переносом владения», а все сложные вещи уходят в обычные функции или в копирование, если оно вообще нужно.
7. Типичные ошибки при работе с noexcept
Ошибка №1: ставить noexcept, потому что «так принято».
Самая частая ловушка — увидеть в интернете Buffer(Buffer&&) noexcept и скопировать, не понимая цену обещания. Если внутри функции есть хоть какой-то сценарий, при котором возможен «выход наружу через исключение», то вы подписываете контракт, нарушение которого завершит программу через std::terminate().
Ошибка №2: пометить noexcept функцию, которая выделяет память.
Новичок иногда думает: «ну у меня же обычно выделяется, значит всё ок». Но «обычно» — не контракт. Выделение памяти — это как попытка найти место на парковке возле ТЦ 31 декабря: иногда получается, иногда нет. Поэтому копирование, которое делает new, почти никогда не стоит помечать noexcept.
Ошибка №3: путать noexcept и const.
Эти слова часто стоят рядом в объявлениях, и мозг пытается их слить в одно. const означает «метод не меняет состояние объекта». noexcept означает «функция не завершится выходом через исключение». Это разные оси: одна про изменения объекта, другая про аварийный путь выхода.
Ошибка №4: усложнить move-операции и забыть пересмотреть noexcept.
Типичная история: сначала move — это перенос указателя, всё честно noexcept. Потом кто-то добавил в move логирование, перерасчёт хеша, создание временного std::string, и move перестал быть таким уж простым. Но noexcept остался. В результате вы получили мину замедленного действия: всё выглядит красиво, но в неожиданный момент программа может аварийно завершиться.
Ошибка №5: думать, что noexcept — это «про оптимизацию, можно не заморачиваться».
Да, noexcept может улучшать поведение и эффективность контейнеров. Но его основной смысл — корректность контракта. Это не тюнинг двигателя, это тормоза. Оптимизация — приятный бонус, а не причина ставить noexcept.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ