Ошибки и неопределённое поведение

Когда программа ведёт себя неправильно, сначала полезно определить, на каком этапе возникла проблема. Если исполняемый файл ещё не получен, искать причину в введённых пользователем числах рано. Если программа уже запустилась, сообщение об ошибке компиляции от прошлой сборки может вообще не относиться к текущему запуску. Разделение на этапы помогает выбрать правильный следующий шаг, а не менять код наугад.

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

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

Флаг -Werror не добавляет новые правила C++ и не превращает компилятор в доказательство правильности программы. Он задаёт более строгую политику сборки: выбранные предупреждения необходимо устранить, прежде чем появится новый исполняемый файл. Если сообщение непонятно, лучше уменьшить пример и выяснить причину, чем сразу выключать соответствующий класс предупреждений для всего проекта.

int main() {
    int x = 1;
    // if (x = 0) {}    // допустимо, но подозрительно
    // x + 5;           // результат выражения не используется
    if (x == 0) {}     // сравнение вместо присваивания
}

Отладка становится спокойнее, когда у вас есть воспроизводимый пример: конкретная версия исходника, команда сборки, входные данные и ожидаемый результат. Это позволяет менять по одной причине за раз и понимать, что повлияло на поведение. Фраза «иногда ломается» менее полезна, чем маленький пример, который показывает проблему при каждом повторении.

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

# Собрать учебный пример на C++20
# g++ -std=c++20 -Wall -Wextra -Wpedantic -Werror -g main.cpp -o app
# ./app

Разобранный пример и самостоятельная проверка

Начните отладку с точного вопроса: какой элемент требуется прочитать и какие индексы существуют? Вектор values содержит три значения, поэтому допустимы номера ноль, один и два. Если запрос равен размеру, подходящего элемента нет. Не нужно запускать чтение за границей и ждать падения: исправление состоит в проверке условия до обращения. В безопасной программе плохой доступ оставлен только комментарием, а выполняемый код сообщает об ошибочном индексе. Сначала запишите ожидаемый исход для каждого теста, затем запускайте программу. Проверка индекса один должна дать двадцать; индекса три — отказ. Если защита случайно использует знак больше вместо больше или равно, именно второй тест обнаружит ошибку. Предупреждения компилятора помогают, но не доказывают, что проверка написана правильно. Тест следует сохранить после исправления, чтобы та же граница не сломалась при следующем изменении программы.

#include <cstddef>
#include <iostream>
#include <vector>

int main() {
    const std::vector<int> values{10, 20, 30};
    const std::size_t index = 3;
    // values[index]; // Не выполнять при index >= values.size().
    if (index >= values.size()) {
        std::cerr << "Invalid index\n";
        return 1;
    }
    std::cout << values[index] << '\n';
}

Один законченный сеанс исправления

1. Симптом: для трёх элементов код пытается прочитать индекс 3. Ожидается отказ.
2. Гипотеза: неверная граница проверки. Плохую операцию не выполняем.
3. Минимальный вход: три значения и индекс 3; обычный контроль — индекс 1.
4. Исправление: до доступа проверить index >= values.size().
5. Повторный тест: 0, size−1 и size; затем пустой набор.

Санитайзеры: g++ -std=c++20 -g -O1 -fsanitize=address,undefined -fno-omit-frame-pointer main.cpp -o app. Они помогают на выполненных путях, но не доказывают отсутствие всех UB и не гарантируют обнаружение любого неинициализированного чтения.

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

Начинайте с первого содержательного сообщения и смотрите не только на выделенную строку, но и немного выше. Спросите себя: узнаваемы ли отдельные символы и токены, правильно ли собрана конструкция, допустимы ли операции для данных типов? Такое разделение не обязано точно повторять устройство конкретного компилятора, но помогает превратить длинный текст диагностики в несколько проверяемых вопросов.

#include <iostream>

int main() {
    int total = 12;
    // std::cout << totla; // Error: undeclared name.
    std::cout << total << '\n';
}

#include <iostream>

int square(int value);

int main() {
    std::cout << square(6) << '\n';
}

int square(int value) {
    return value * value;
}

#include <string>
int main() {
    int x = 3;
    // x = 5 + ;                // синтаксическая ошибка
    // std::string s = "abc";
    // auto y = s * 3;          // семантическая ошибка
    // unknown_name = 1;       // имя не объявлено
    return x;
}

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

#include <vector>
#include <stdexcept>
#include <iostream>
int main() {
    std::vector<int> v = {10, 20, 30};
    // v[3] = 5;          // UB: вне диапазона
    try {
        std::cout << v.at(3);
    } catch (const std::out_of_range&) {
        std::cout << "Неверный индекс";
    }
}

Сравните обращение values.at(index) с values[index]. В первом случае ошибка индекса сообщает о себе через предусмотренное библиотекой исключение, которое можно обработать. Во втором выход за допустимые границы не превращается автоматически в такое же исключение. Если программа «случайно не упала», это ещё не делает чтение корректным: нужно проверить индекс до обращения или выбрать операцию с проверкой.

#include <iostream>
#include <stdexcept>
#include <vector>

int main() {
    std::vector<int> values{10, 20};
    try {
        std::cout << values.at(4) << '\n';
    } catch (const std::out_of_range&) {
        std::cout << "Invalid index\n";
    }
}

#include <iostream>
#include <sstream>

int main() {
    std::istringstream input{"-3"};
    int count = 0;
    if (!(input >> count) || count < 0) {
        std::cout << "Expected a nonnegative count\n";
        return 0;
    }
    std::cout << "Count: " << count << '\n';
}

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

Например, у вектора с тремя элементами допустимы обычные индексы от нуля до двух. Обращение к четвёртому элементу не становится безопасным оттого, что рядом с буфером оказалась доступная память. Чтобы исправить программу, нужно восстановить правильную границу обхода или изменить логику хранения. Перехватывать только видимое падение недостаточно: некорректное действие могло остаться незаметным.

#include <climits>
#include <vector>
void demo() {
    int x = INT_MAX;
    // ++x;                   // UB: signed overflow
    int i = 0;
    // int z = i++ + i++;     // UB: неупорядоченные изменения
    std::vector<int> v(3);
    // int a = v[3];          // UB: индекс вне границ
}

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

Если порядок двух допустимых независимых действий не указан, нельзя требовать один заранее выбранный порядок, но и говорить «разрешено абсолютно всё» неверно. Если свойство определяется реализацией, его можно узнать из документации используемых инструментов и платформы. А при UB документация об одном наблюдаемом запуске не заменяет исправления программы. Сначала назовите категорию, затем решайте, на что можно опираться.

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

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

#include <iostream>
#include <limits>

bool add(int left, int right, int& result) {
    const int maximum = std::numeric_limits<int>::max();
    const int minimum = std::numeric_limits<int>::min();
    if ((right > 0 && left > maximum - right) ||
        (right < 0 && left < minimum - right)) {
        return false;
    }
    result = left + right;
    return true;
}

int main() {
    int result = 0;
    if (!add(std::numeric_limits<int>::max(), 1, result)) {
        std::cout << "Overflow prevented\n";
    }
    if (add(20, 22, result)) {
        std::cout << result << '\n';
    }
}

#include <iostream>
#include <limits>

int main() {
    unsigned int count = 0;
    --count;
    bool at_maximum = count == std::numeric_limits<unsigned int>::max();
    std::cout << std::boolalpha << at_maximum << '\n';
}

#include <iostream>
#include <limits>
int main() {
    for (int i = 173; i <= 174; ++i) {
        const long long product = 1LL * i * 12'345'678;
        std::cout << i << ": " << product;
        if (product > std::numeric_limits<int>::max()) {
            std::cout << " outside int";
        }
        std::cout << '\n';
    }
    // int overflow = 174 * 12'345'678; // Не выполнять: UB для 32-bit int.
}