assert — runtime‑предохранитель для инвариантов

1. Основная идея: инварианты и раннее падение

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

Санитайзеры отлично ловят классы проблем, но они не умеют читать ваши мысли. Например, санитайзер может сказать «out of bounds», но не скажет «ты же обещал, что id задачи всегда положительный, а он вдруг стал -17». Вот здесь assert работает как маленький «датчик здравого смысла»: вы в коде фиксируете ожидание, которое должно быть истинным, если логика программы корректна.

Полезная метафора: санитайзер — это металлоискатель на входе в аэропорт, а assert — это чек‑лист пилота перед взлётом. Металлоискатель ловит много опасного, но чек‑лист проверяет то, что важно именно для этого самолёта прямо сейчас.

Инвариант и ошибка пользователя

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

Ключевой момент: инвариант — это обычно наше внутреннее обещание, а не договор с пользователем. Пользователь может ввести ерунду: пустую строку, буквы вместо числа, отрицательный id — и это не “ошибка программы”, это обычная реальность. Такие ситуации мы обрабатываем через if, сообщения об ошибке и возврат “не получилось”.

А вот если мы внутри программы сами рассчитали индекс и неожиданно получили i == v.size(), или сами сгенерировали id и он вдруг стал 0, — это уже не «ошибка пользователя». Это значит, что наша логика дала сбой, и продолжать выполнение часто опасно (можно уехать в UB). Именно такие случаи и покрывает assert.

2. Как работает assert в C++

Базовый синтаксис: как включить и как выглядит падение

assert в C++ — это макрос, который подключается через заголовок <cassert>. Макрос — важное слово: это не функция, а конструкция, которая разворачивается препроцессором. Поэтому у assert есть особенность: при некоторых настройках сборки он может превратиться в «ничего», то есть условие даже не будет вычисляться (об этом чуть позже).

Минимальный пример:

#include <cassert>

int main() {
    int x = 10;
    assert(x > 0); // ок, условие истинно
}

Если условие ложно, программа аварийно завершится. Обычно вы увидите сообщение вроде “assertion failed” и координаты (зависят от платформы и сборки). Важно: assert предназначен не для «красивого UX», а для разработчика, который хочет сразу понять: “мы приехали в невозможное состояние”.

Исторический факт из мира стандартов: даже вокруг assert бывают улучшения и обсуждения того, «как сделать диагностику дружелюбнее». Например, в документах WG21 есть отдельные пункты про изменения, связанные с тем, чтобы сделать assert() более “user friendly” в C и C++.

Куда ставить assert

Почти все полезные assert в реальном коде стоят в двух местах:

1. перед потенциально опасной операцией, которая при неправильных данных может привести к UB или к бессмысленному результату;
2. после изменения состояния, когда мы хотим убедиться, что объект/контейнер остался в корректном состоянии.

Почему это важно? Потому что assert должен ловить проблему как можно ближе к первопричине. Если поставить его слишком поздно, вы получите падение в неожиданном месте, а реальная ошибка могла случиться на 20 строк раньше. Если поставить его слишком рано и слишком общо, он будет срабатывать «то ли по делу, то ли просто потому что жизнь сложная».

Пример “до опасной строки” — деление:

#include <cassert>

int Divide(int a, int b) {
    assert(b != 0);
    return a / b;
}

Пример “до опасной строки” — индексирование:

#include <cassert>
#include <vector>

int GetAt(const std::vector<int>& v, std::size_t i) {
    assert(i < v.size());
    return v[i]; // если условие нарушено, лучше упасть ДО этой строки
}

Пример “после изменения состояния” — мы добавили элемент и хотим убедиться, что контейнер не стал пустым:

#include <cassert>
#include <vector>

void AddOne(std::vector<int>& v, int x) {
    v.push_back(x);
    assert(!v.empty());
}

NDEBUG: почему assert может «исчезнуть»

Самый важный “подводный камень” здесь такой: assert часто работает так, что в Debug‑сборке он активен, а в Release‑сборке может быть отключён. Отключение обычно связано с макросом NDEBUG: если он определён, assert(...) превращается в пустую конструкцию.

Практический вывод: нельзя строить логику программы так, чтобы без assert она работала иначе. assert — это не «если что, сделай важное действие», а «если что, проверь условие». И всё.

Вот пример плохого кода — assert с побочным эффектом:

#include <cassert>

int main() {
    int x = 0;
    assert(++x == 1); // плохо: меняем x внутри assert
    // в Release это может превратиться в "ничего",
    // и тогда x так и останется 0
}

А вот хороший вариант: сначала сделать действие, потом проверить:

#include <cassert>

int main() {
    int x = 0;
    ++x;
    assert(x == 1); // хорошо: проверка не меняет состояние
}

Запомните простое правило: выражение внутри assert(...) должно быть максимально «чистым», без изменений переменных и без вызовов функций, которые что‑то меняют.

Как сделать падение понятнее: сообщение в assert

У assert есть одно приятное свойство: вы можете сделать условие чуть более «говорящим», чтобы при падении сразу было ясно, какой контракт нарушен. В идеале программист, увидев упавший assert, должен за 10 секунд понять, что пошло не так, а не открывать бубен и читать весь проект с начала.

Классический трюк (без побочных эффектов) — добавить строковый литерал через &&. Если условие ложно, итог тоже ложен, и assert сработает:

#include <cassert>
#include <vector>

int GetAt(const std::vector<int>& v, std::size_t i) {
    assert(i < v.size() && "index must be within vector bounds");
    return v[i];
}

Почему это работает? Потому что "text" — это указатель на строковый литерал, он “истинный” в логическом смысле, и в норме выражение сводится к проверке i < v.size(). А текст помогает вам (или вашему тимлиду в 3 часа ночи) быстрее понять смысл инварианта.

Важно: это именно подсказка разработчику. Для пользователя мы такие сообщения не показываем (и вообще assert не про пользователя).

3. Пример: добавляем assert в TaskKeeper

Чтобы assert не остался «академическим зверем», давайте встроим его в учебное консольное приложение. Предположим, у нас есть простой менеджер задач: храним список задач (std::vector), у каждой задачи есть id, title, и флаг done. Приложение умеет добавлять задачу, отмечать выполненной и печатать список.

Модель

#include <string>

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

Генерация id

Здесь инвариант простой: id всегда положительный, а nextId всегда больше нуля.

#include <cassert>

int GenerateId(int& nextId) {
    assert(nextId > 0 && "nextId must stay positive");
    int id = nextId;
    ++nextId;
    assert(id > 0);
    return id;
}

Обратите внимание на стиль: мы не “лечим” ситуацию, когда nextId <= 0. Мы считаем её логически невозможной при корректном коде. Значит, если это случилось — лучше упасть и разбираться.

Добавление задачи

Здесь есть две категории проверок:

• “пользовательская”: заголовок может быть пустым, и это нормальная ситуация, мы просто не добавим задачу;
• “наша внутренняя”: если мы добавили задачу, её id должен быть валидным, а вектор после добавления не должен внезапно стать меньше.

#include <cassert>
#include <string>
#include <vector>

bool AddTask(std::vector<Task>& tasks, int& nextId, const std::string& title) {
    if (title.empty()) return false;               // ошибка пользователя/ввода

    const std::size_t oldSize = tasks.size();
    Task t;
    t.id = GenerateId(nextId);
    t.title = title;

    tasks.push_back(t);
    assert(tasks.size() == oldSize + 1);
    assert(tasks.back().id > 0);
    return true;
}

Поиск по id

Здесь удобно возвращать индекс. Мы уже знакомы с std::optional из предыдущих тем, и это хороший случай: “нашли/не нашли” — это нормальный исход, а не авария.

Но и тут можно поставить assert на внутренний контракт: если мы возвращаем индекс, он точно в пределах tasks.size().

#include <cassert>
#include <optional>
#include <vector>

std::optional<std::size_t> FindTaskIndexById(const std::vector<Task>& tasks, int id) {
    if (id <= 0) return std::nullopt; // пользователь мог ввести ерунду

    for (std::size_t i = 0; i < tasks.size(); ++i) {
        if (tasks[i].id == id) {
            assert(i < tasks.size());
            return i;
        }
    }
    return std::nullopt;
}

Пометить выполненной

Тут типичная ловушка: мы нашли индекс, а потом делаем tasks[index]. Если вдруг индекс неправильный — это кандидат на UB. Поэтому мы ставим assert прямо перед доступом, даже если «логически индекс уже проверен». Это как второй ремень безопасности: он почти никогда не срабатывает, но когда срабатывает — вы рады, что он был.

#include <cassert>
#include <optional>
#include <vector>

bool MarkDone(std::vector<Task>& tasks, int id) {
    const auto idx = FindTaskIndexById(tasks, id);
    if (!idx) return false;

    assert(*idx < tasks.size());
    tasks[*idx].done = true;
    return true;
}

Минимальный main

Без усложнений ввода — здесь мы тренируем именно assert.

#include <iostream>
#include <vector>

int main() {
    std::vector<Task> tasks;
    int nextId = 1;

    AddTask(tasks, nextId, "Read about assert");
    AddTask(tasks, nextId, "Fix UB before it fixes you");

    MarkDone(tasks, 1);

    for (const auto& t : tasks) {
        std::cout << t.id << ". " << t.title
                  << (t.done ? " [done]" : " [todo]") << '\n';
        // 1. Read about assert [done]
        // 2. Fix UB before it fixes you [todo]
    }
}

Смысл этого фрагмента не в том, чтобы сделать идеальный менеджер задач, а в том, чтобы увидеть, как assert фиксирует наши внутренние обещания: “id положительный”, “индекс в границах”, “после push_back размер вырос на 1”.

4. assert в отладке и связка с санитайзерами

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

Полезно держать в голове простую схему того, как мы “накрываем” ошибки слоями:

flowchart TD
    A[Ошибка логики: нарушили инвариант] --> B[assert срабатывает сразу]
    A --> C[если assert нет: идём дальше]
    C --> D[может случиться UB]
    D --> E[санитайзер ловит часть UB]
    D --> F[без санитайзера: странные симптомы]

Практическое правило: если у вас есть место, где потенциально может произойти UB (индексирование, деление, сдвиг), то assert до операции часто превращает «странную проблему через 5 минут» в «понятный крэш прямо здесь».

5. Типичные ошибки при использовании assert

Ошибка №1: использовать assert для проверки пользовательского ввода.
Когда пользователь вводит неправильный id или пустую строку, это не “невозможное состояние”, это нормальная ветка программы. Если вы поставите assert(id > 0) на входе команды, программа будет падать от любого неправильного ввода. Это не защита, а способ поссориться с пользователем. Для таких случаев нужен обычный if и аккуратное сообщение/возврат “не получилось”.

Ошибка №2: закладываться на assert как на обязательную часть логики.
Из‑за того, что assert может быть отключён через NDEBUG, нельзя писать код так, чтобы внутри assert были важные действия. Любой побочный эффект в условии (++x, запись в контейнер, изменение флага) превращает ваш Release‑билд в версию программы с другой логикой. А потом вы будете долго объяснять, почему “в дебаге работает”.

Ошибка №3: ставить assert после опасной операции.
Иногда встречается конструкция “сначала читаем v[i], потом проверяем i < v.size()”. Это уже поздно: если индекс неверный, UB мог произойти на строке чтения, а проверка ниже не спасает. assert должен стоять перед потенциально опасной строкой, иначе это просто декоративная табличка “Осторожно, тут был обрыв”.

Ошибка №4: делать assert слишком общими и бессмысленными.
assert(true) и assert(x == x) фиксируют никакой реальной идеи. Хороший assert должен выражать конкретный контракт: “индекс в границах”, “размер увеличился”, “id положительный”, “указатель не null”. Если вы не можете объяснить словами, зачем именно этот assert здесь стоит, скорее всего он вам не поможет.

Ошибка №5: превращать код в “минное поле assert’ов”.
assert — мощная штука, но если вставлять его каждые две строки “на всякий случай”, код становится нечитаемым и нервным. Лучше ставить assert в местах, где есть чёткий контракт: на границах функций, перед опасными операциями, после важных изменений состояния. Тогда каждый assert будет как хорошая дорожная разметка, а не как граффити на каждой стене.