Псевдоним T * с символом * разрешен. Это также разрешено наоборот?

Часть вашего кода сомнительна из-за задействованных преобразований указателей. Имейте в виду, что в этих случаях reinterpret_cast<T*>(e) имеет семантику static_cast<T*>(static_cast<void*>(e)) потому что типы, которые вовлечены, являются стандартным расположением. (Я бы порекомендовал вам всегда использование static_cast с помощью cv void* когда дело касается хранения.)

Внимательное прочтение стандарта предполагает, что во время преобразования указателя в или из T* предполагается, что действительно существует реальный объект T* вовлеченный — который трудно выполнить в некоторых ваших фрагментах, даже когда он «обманывает» благодаря тривиальности задействованных типов (подробнее об этом позже). Это было бы, кроме того, потому что …

Псевдоним не о преобразованиях указателей. Это текст C ++ 11, в котором изложены правила, которые обычно называются правилами «строгого алиасинга», из 3.10 Lvalues ​​и rvalues ​​[basic.lval]:

10 Если программа пытается получить доступ к сохраненному значению объекта через glvalue другого, чем один из следующих типов, поведение не определено:

• динамический тип объекта,
• cv-квалифицированная версия динамического типа объекта,
• тип, подобный (как определено в 4.4) динамическому типу объекта,
• тип, который является типом со знаком или без знака, соответствующим динамическому типу объекта,
• тип, который является типом со знаком или без знака, соответствующим cv-квалифицированной версии динамического типа объекта,
• агрегатный или объединенный тип, который включает в себя один из вышеупомянутых типов среди своих элементов или нестатических элементов данных (включая, рекурсивно, элемент или нестатический элемент данных субагрегата или содержащего объединения),
• тип, который является (возможно, квалифицированным cv) типом базового класса динамического типа объекта,
• тип char или unsigned char.

(Это абзац 15 того же пункта и подпункта в C ++ 03, с некоторыми незначительными изменениями в тексте с использованием, например, «lvalue» вместо «glvalue», поскольку последний является понятием C ++ 11.)

В свете этих правил давайте предположим, что реализация предоставляет нам magic_cast<T*>(p) который «каким-то образом» преобразует указатель в другой тип указателя. Обычно это было бы быть reinterpret_cast, который в некоторых случаях дает неуказанные результаты, но, как я объяснил ранее, это не так для указателей на типы стандартной компоновки. Тогда совершенно верно, что все ваши фрагменты верны (заменяя reinterpret_cast с magic_cast), потому что никакие глюки не связаны вообще с результатами magic_cast,

Вот фрагмент, который появляется неправильно использовать magic_cast, но я буду утверждать, это правильно:

// assume constexpr max
constexpr auto alignment = max(alignof(int), alignof(short));
alignas(alignment) char c[sizeof(int)];
// I'm assuming here that the OP really meant to use &c and not c
// this is, however, inconsequential
auto p = magic_cast<int*>(&c);
*p = 42;
*magic_cast<short*>(p) = 42;

Чтобы оправдать мои рассуждения, предположим, что это поверхностно другой фрагмент:

// alignment same as before
alignas(alignment) char c[sizeof(int)];

auto p = magic_cast<int*>(&c);
// end lifetime of c
c.~decltype(c)();
// reuse storage to construct new int object
new (&c) int;

*p = 42;

auto q = magic_cast<short*>(p);
// end lifetime of int object
p->~decltype(0)();
// reuse storage again
new (p) short;

*q = 42;

Этот фрагмент тщательно построен. В частности, в new (&c) int; Мне разрешено использовать &c даже если c был уничтожен по правилам, изложенным в пункте 5 из 3.8 Срок службы объекта [basic.life]. В параграфе 6 того же самого правила очень похожи на ссылки на хранилище, а в параграфе 7 объясняется, что происходит с переменными, указателями и ссылками, которые использовались для ссылки на объект после повторного использования его хранилища — я буду называть их как 3.8 / 5- 7.

В этом случае &c (неявно) преобразуется в void*, что является одним из правильного использования указателя на хранилище, которое еще не использовалось. так же p получается из &c перед новым int построен Его определение может быть перенесено после уничтожения cв зависимости от того, насколько глубока магия реализации, но, конечно, не после int Конструкция: пункт 7 будет применяться, и это не одна из разрешенных ситуаций. Строительство short объект также опирается на p становится указателем на хранилище.

Теперь, потому что int а также short тривиальные типы, мне не нужно использовать явные вызовы деструкторов. Мне также не нужны явные вызовы конструкторам (то есть вызовы обычного стандартного размещения, объявленного в <new>). С 3.8 Срок жизни объекта [basic.life]:

1 […] Время жизни объекта типа T начинается, когда:

• хранение с правильным выравниванием и размером для типа T, и
• если объект имеет нетривиальную инициализацию, его инициализация завершена.

Время жизни объекта типа T заканчивается, когда:

• если T является типом класса с нетривиальным деструктором (12.4), начинается вызов деструктора, или
• хранилище, которое занимает объект, используется повторно или освобождается.

Это означает, что я могу переписать код так, чтобы после сворачивания промежуточной переменной qЯ заканчиваю с оригинальным фрагментом.

Обратите внимание, что p нельзя сложить То есть следующее определенно неверно:

alignas(alignment) char c[sizeof(int)];
*magic_cast<int*>(&c) = 42;
*magic_cast<short*>(&c) = 42;

Если мы предположим, что int объект (тривиально) строится со второй строкой, тогда это должно означать &c становится указателем на хранилище, которое было повторно использовано. Таким образом, третья строка неверна — хотя из-за 3.8 / 5-7, а не из-за правил псевдонимов, строго говоря.

Если мы этого не предполагаем, то вторая строка является нарушение правил псевдонимов: мы читаем, что на самом деле char c[sizeof(int)] объект через glvalue типа int, что не является одним из разрешенных исключений. По сравнению, *magic_cast<unsigned char>(&c) = 42; было бы хорошо (мы предполагаем, short объект тривиально построен на третьей строке).

Как и Alf, я бы также порекомендовал вам использовать стандартное размещение как новое при использовании хранилища. Пропуск уничтожения для тривиальных типов это хорошо, но при встрече *some_magic_pointer = foo; вы, скорее всего, столкнетесь либо с нарушением 3.8 / 5-7 (независимо от того, каким волшебным образом был получен этот указатель), либо с правилами наложения имен. Это также означает сохранение результата нового выражения, так как вы, скорее всего, не сможете повторно использовать магический указатель после того, как ваш объект создан — снова из-за 3.8 / 5-7.

Чтение байтов объекта (это означает использование char или же unsigned char) хорошо, но вы даже не используете reinterpret_cast или что-нибудь волшебное вообще. static_cast с помощью cv void* возможно, подходит для этой работы (хотя я чувствую, что Стандарт мог бы использовать там более качественную формулировку).