обработка памяти, возвращаемой оператором new (sizeof (T) * N) как массив

Стандарты C ++ содержат открытую проблему, которая базовое представление объектов - это не «массив», а «последовательность» unsigned char объектов. Тем не менее, все рассматривают его как массив (что и задумано), поэтому можно безопасно писать такой код:

char* storage = static_cast<char*>(operator new(sizeof(T)*size));
// ...
char* p = storage + sizeof(T)*i;  // precondition: 0 <= i < size
new (p) T(element);

пока void* operator new(size_t) возвращает правильно выровненное значение. Использование смещений, умноженных на sizeof, для сохранения выравнивания безопасно.

В C ++ 17 есть макрос STDCPP_DEFAULT_NEW_ALIGNMENT < / a>, который определяет максимальное безопасное выравнивание для "нормального" void* operator new(size_t), и void* operator new(std::size_t size, std::align_val_t alignment) следует использовать, если требуется большее выравнивание.

Проблема арифметики указателя на выделенную память, как в вашем примере:

T* storage = static_cast<T*>(operator new(sizeof(T)*size));
// ...
T* p = storage + i;  // precondition: 0 <= i < size
new (p) T(element);

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

Комитет по стандартам определенно не намеревался сделать std::vector невыполнимым. Саттер, конечно, прав в том, что такой код предназначен для четкого определения. Формулировка стандарта должна это отражать.

P0593 - это предложение, которое, если оно будет принято в стандарте, может решить эту проблему. А пока можно продолжать писать код, подобный приведенному выше; ни один крупный компилятор не будет рассматривать его как UB.

Изменить: Как указано в комментариях, я должен был сказать, что, когда я сказал, что storage + i будет четко определен в P0593, я предполагал, что элементы storage[0], storage[1], ..., storage[i-1] уже были был построен. Хотя я не уверен, что понимаю P0593 достаточно хорошо, чтобы сделать вывод, что он также не охватывает случай, когда эти элементы не были уже созданы.

Ко всем широко используемым современным posix-совместимым системам, то есть Windows, Linux (и Android и т. Д.), И MacOSX применимо следующее:

Можно ли использовать malloc () для динамических массивов в C ++?

Да, это так. Использование reinterpret_cast для преобразования результирующего void* в желаемый тип указателя является наилучшей практикой, и в результате получается динамически распределенный массив, подобный этому: type *array = reinterpret_cast<type*>(malloc(sizeof(type)*array_size); Будьте осторожны, в этом случае конструкторы не вызываются для элементов массива, поэтому это по-прежнему неинициализированное хранилище, независимо от того, что type. Деструкторы не вызываются, когда free используется для освобождения

Можно ли использовать оператор new () и размещение new для динамических массивов в более старом C ++, в котором нет ключевого слова alignas?

Да, но вам нужно знать о выравнивании в случае размещения new, если вы вводите в него пользовательские местоположения (то есть те, которые не поступают из malloc / new). Обычный оператор new, а также malloc предоставят собственные области памяти, выровненные по словам (по крайней мере, всякий раз, когда размер выделения> = wordize). Этот факт, а также тот факт, что макеты и размеры структуры определены таким образом, чтобы выравнивание учитывалось должным образом, вам не нужно беспокоиться о выравнивании массивов dyn, если используется malloc или new. Можно заметить, что размер слова иногда значительно меньше, чем самый большой встроенный тип данных (который обычно равен long double), но он должен быть выровнен таким же образом, поскольку выравнивание касается не размера данных, а разрядности адресов на шине памяти для разных размеров доступа.

Не определено ли поведение арифметики указателя при использовании в памяти, возвращаемой оператором new ()?

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

Саттер советует код, который может сломаться на какой-нибудь старинной машине?

Я так не думаю, если используется правильный компилятор. (не компилируйте инструкции avr или mov с 128-битной памятью в двоичный файл, предназначенный для работы на 80386) Конечно, на разных машинах с разными размерами памяти и разметкой один и тот же буквальный адрес может иметь доступ к областям с разным назначением / статусом / Существование, но зачем вам использовать буквальные адреса, если вы не пишете код драйвера для конкретного оборудования? ... :)