Каковы все общие неопределенные поведения, о которых должен знать программист на C ++?

Указатель

• Разыменование указателя NULL
• Разыменование указателя, возвращаемого новым выделением нулевого размера
• Использование указателей на объекты, время жизни которых закончилось (например, выделенные стеком объекты или удаленные объекты)
• Разыменование указателя, который еще не был определенно инициализирован
• Выполнение арифметики указателя, которая дает результат за пределами границ (выше или ниже) массива.
• Разыменование указателя в месте за концом массива.
• Преобразование указателей в объекты несовместимых типов
• Использование memcpy для копирования перекрывающихся буферов.

Переполнение буфера

• Чтение или запись в объект или массив со смещением, которое отрицательно или превышает размер этого объекта (переполнение стека / кучи)

Целочисленные переполнения

• Подписанное целочисленное переполнение
• Оценка выражения, которое не определено математически
• Значения со смещением влево на отрицательную величину (смещение вправо на отрицательные значения определяется реализацией)
• Сдвиг значений на величину, большую или равную количеству бит в числе (например, int64_t i = 1; i <<= 72 не определено)

Типы, приведение и константа

• Преобразование числового значения в значение, которое не может быть представлено целевым типом (напрямую или через static_cast)
• Использование автоматической переменной до того, как она будет определенно назначена (например, int i; i++; cout << i;)
• Использование значения любого объекта типа, отличного от volatile или sig_atomic_t при получении сигнала
• Попытка изменить строковый литерал или любой другой константный объект во время его существования
• Соединение узкого строкового литерала с широким во время предварительной обработки

Функция и шаблон

• Невозможность возврата значения из функции, возвращающей значение (напрямую или путем передачи из блока try)
• Несколько разных определений для одной и той же сущности (класс, шаблон, перечисление, встроенная функция, статическая функция-член и т. Д.)
• Бесконечная рекурсия при создании экземпляров шаблонов
• Вызов функции с использованием других параметров или привязка к параметрам и привязке, которые функция определена как использующая.

ООП

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

Исходный файл и предварительная обработка

• Непустой исходный файл, который не заканчивается новой строкой или заканчивается обратной косой чертой (до C ++ 11)
• Обратная косая черта, за которой следует символ, который не является частью указанных escape-кодов в символьной или строковой константе (это определяется реализацией в C ++ 11).
• Превышение ограничений реализации (количество вложенных блоков, количество функций в программе, доступное пространство стека ...)
• Числовые значения препроцессора, которые не могут быть представлены long int
• Директива предварительной обработки в левой части определения макроса, подобного функции
• Динамическое создание определенного токена в выражении #if

Быть классифицированным

• Вызов exit при уничтожении программы со статической продолжительностью хранения

Порядок оценки параметров функции - неопределенное поведение. (Это не приведет к сбою, взрыву программы или заказу пиццы ... в отличие от неопределенного поведения.)

Единственное требование - все параметры должны быть полностью вычислены перед вызовом функции.

Этот:

// The simple obvious one.
callFunc(getA(),getB());

Может быть эквивалентно этому:

int a = getA();
int b = getB();
callFunc(a,b);

Или это:

int b = getB();
int a = getA();
callFunc(a,b);

Это может быть либо; это зависит от компилятора. Результат может иметь значение, в зависимости от побочных эффектов.

Компилятор может изменить порядок оцениваемых частей выражения (при условии, что значение не изменилось).

Из исходного вопроса:

a[i] = i++;

// This expression has three parts:
(a) a[i]
(b) i++
(c) Assign (b) to (a)

// (c) is guaranteed to happen after (a) and (b)
// But (a) and (b) can be done in either order.
// See n2521 Section 5.17
// (b) increments i but returns the original value.
// See n2521 Section 5.2.6
// Thus this expression can be written as:

int rhs  = i++;
int lhs& = a[i];
lhs = rhs;

// or
int lhs& = a[i];
int rhs  = i++;
lhs = rhs;

Двойная проверка блокировки. И одна простая ошибка.

A* a = new A("plop");

// Looks simple enough.
// But this can be split into three parts.
(a) allocate Memory
(b) Call constructor
(c) Assign value to 'a'

// No problem here:
// The compiler is allowed to do this:
(a) allocate Memory
(c) Assign value to 'a'
(b) Call constructor.
// This is because the whole thing is between two sequence points.

// So what is the big deal.
// Simple Double checked lock. (I know there are many other problems with this).
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        a = new A("Plop");  // (Point A).
    }
}
a->doStuff();

// Think of this situation.
// Thread 1: Reaches point A. Executes (a)(c)
// Thread 1: Is about to do (b) and gets unscheduled.
// Thread 2: Reaches point B. It can now skip the if block
//           Remember (c) has been done thus 'a' is not NULL.
//           But the memory has not been initialized.
//           Thread 2 now executes doStuff() on an uninitialized variable.

// The solution to this problem is to move the assignment of 'a'
// To the other side of the sequence point.
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        A* tmp = new A("Plop");  // (Point A).
        a = tmp;
    }
}
a->doStuff();

// Of course there are still other problems because of C++ support for
// threads. But hopefully these are addresses in the next standard.

Мне больше всего нравится «Бесконечная рекурсия при создании экземпляров шаблонов», потому что я считаю, что это единственный вариант, в котором неопределенное поведение возникает во время компиляции.

Назначение константе после удаления constness с помощью const_cast<>:

const int i = 10; 
int *p =  const_cast<int*>( &i );
*p = 1234; //Undefined

Помимо неопределенного поведения, существует также не менее неприятное поведение, определяемое реализацией.

Неопределенное поведение возникает, когда программа делает что-то, результат чего не определен стандартом.

Поведение, определяемое реализацией - это действие программы, результат которого не определен стандартом, но который реализация должна задокументировать. Примером могут служить «Многобайтовые символьные литералы» из вопроса о переполнении стека Есть ли компилятор C, который не может это скомпилировать? < / em>.