В чем разница между undefined, unspecified и implementation-defined behavior в C++?

Разбираем три уровня неопределенности в C++

Отличный вопрос! Вы затронули фундаментальную тему, которая отличает C++ от многих других языков. Понимание этих трех категорий — ключ к написанию переносимого и предсказуемого кода. Давайте разберем каждую на пальцах.

1. Unspecified Behavior (Неспецифицированное поведение)

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

int x = foo() + bar(); // Порядок вызова foo() и bar() не указан

Стандарт говорит: "Порядок вычисления операндов оператора + неспецифицирован". Это значит, что компилятор может вызвать foo() первым, а потом bar(), или наоборот. Оба варианта корректны с точки зрения стандарта. Программа не сломается (если функции не имеют побочных эффектов, влияющих друг на друга), но результат может отличаться при смене компилятора или версии. Unspecified behavior — это "выбери любой из списка".

2. Implementation-defined Behavior (Определяемое реализацией поведение)

Здесь стандарт говорит: "Результат зависит от реализации, но реализация обязана задокументировать свой выбор". Ваш пример с sizeof(int) — это оно. Компилятор (и платформа) решает, сколько байт занимает int, и обязан указать это в документации (например, в мануале GCC или MSVC). Другой пример — знак char по умолчанию (signed char или unsigned char).

// На одной платформе sizeof(int) == 4, на другой == 2
// Компилятор обязан это документировать
int a = sizeof(int); // Implementation-defined, но предсказуемо для данной платформы

Implementation-defined behavior — это "выбери что-то одно, но запиши в инструкцию". Код, полагающийся на него, не является переносимым, но он не сломается, пока вы остаетесь на одной платформе с одной версией компилятора.

3. Undefined Behavior (Неопределенное поведение)

Это самое страшное. Стандарт говорит: "Я не накладываю никаких ограничений. Может произойти абсолютно что угодно". Программа может упасть, выдать неверный результат, стереть ваш жесткий диск (теоретически) или, что самое коварное, работать как ни в чем не бывало до определенного момента. Пример со сдвигом знакового числа — это UB.

int x = 1;
int y = x << 33; // UB, если sizeof(int) == 4 (32 бита)
// Компилятор может сгенерировать любой код: от "ничего" до "форматирования диска"

Почему это UB, а не "странный результат"? Потому что на разных архитектурах процессоры по-разному обрабатывают такие сдвиги. На x86 инструкция shl использует только младшие 5 бит счетчика (для 32-битных операндов), поэтому 1 << 33 даст 2. На ARM — другое поведение. Чтобы не заставлять компилятор генерировать проверки (что замедлило бы код), стандарт просто объявил это UB. Undefined behavior — это "делай что хочешь, мы за результат не отвечаем".

Сводная таблица для запоминания

• Unspecified behavior: Несколько вариантов, любой из них корректен. Документация не обязательна. Пример: порядок вычисления аргументов.
• Implementation-defined behavior: Один вариант, но он зависит от платформы. Документация обязательна. Пример: размер int.
• Undefined behavior: Абсолютно любой результат (вплоть до краха). Документация не нужна, так как это "зона без правил". Пример: выход за границы массива, разыменование нулевого указателя.

Совет: всегда избегайте UB, аккуратно работайте с unspecified behavior (если код не должен быть переносимым или вы контролируете порядок), и четко документируйте, если полагаетесь на implementation-defined behavior.

// Вместо:
int x = foo() + bar(); // Неясно, кто первый

// Пишите так:
int a = foo();
int b = bar();
int x = a + b; // Порядок четкий: сначала foo, потом bar