Четко ли определен этот тип каламбура?

Вы не можете этого сделать: &reinterpret_cast<PunnerToUInt32*>(&x)

В правилах reinterpret_cast говорится:

Когда указатель или ссылка на объект, динамический тип которого DynamicType, reinterpret_cast (или приведение в стиле C) к указателю или ссылке на объект другого типа AliasedType, приведение всегда выполняется успешно, но полученный указатель или ссылка могут использоваться только для получить доступ к объекту, если выполнено одно из следующих условий:

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

Поскольку ничто из этого не верно для комбинации DynamicType равно float и AliasedType равно PunnerToUInt32, указатель не может использоваться для доступа к объекту, что вы делаете. Делаем поведение неопределенным.

Для получения дополнительной информации см .: Почему reinterpret_cast не принудительно копирует copy_n для преобразований между типами одинакового размера?

РЕДАКТИРОВАТЬ:

Разбивая на части 4 ^th bullet int bite size, получаем:

1. "AliasedType"
   Здесь принято PunnerToUInt32

2. "является агрегатным типом или типом объединения"
   PunnerToUInt32 соответствует требованиям, поскольку он отвечает требованиям тип агрегата:

   • array type
   • class type (typically, struct or union), that has
     • no private or protected non-static data members
     • никаких конструкторов, предоставляемых пользователем, в том числе унаследованных от общедоступных баз (разрешены явно заданные по умолчанию или удаленные конструкторы)
     • нет виртуальных, частных или защищенных базовых классов
     • нет виртуальных функций-членов

3. "который содержит один из вышеупомянутых типов в качестве элемента или нестатического члена (включая, рекурсивно, элементы субагрегатов и нестатические элементы данных содержащихся объединений)"
   И снова PunnerToUInt32 подходит, потому что он float fl член

4. "это делает безопасным получение полезного указателя на структуру или объединение"
   Это последняя правильная часть, поскольку AliassedType - это PunnerToUInt32
5. "указан указатель на его нестатический член или элемент"
   Это нарушение, потому что DynamicType, который равен x, не является членом PunnerToUInt32

Из-за нарушения части 5 работа с этим указателем имеет неопределенное поведение.

Если вас интересуют некоторые рекомендуемые материалы, вы можете проверить Оптимизацию пустой базы, если нет Я дам вам здесь первостепенное значение:

Для StandardLayoutTypes требуется пустая базовая оптимизация, чтобы поддерживать требование, чтобы указатель на объект стандартного макета, преобразованный с использованием reinterpret_cast, указывал на его начальный член.

Таким образом, вы можете использовать пулю 4 ^th reinterpret_cast, выполнив следующие действия:

PunnerToUInt32 x = {13, 42.0F};
auto y = reinterpret_cast<PunnerToUInt32*>(&x.ui32);

Живой пример

Если бы p_x_as_uint32 каким-то образом указывал на x ¹, тогда *p_x_as_uint32=5 обращался бы к объекту типа float через glvalue типа uint32_t, что привело бы к неопределенному поведению.

Речь идет о «доступе», и все, что имеет значение, - это тип используемого glvalue (uint32_t) и фактический тип объекта, к которому осуществляется доступ (float). Мучительная серия забросов, использованная для получения указателя, не имеет значения.

Стоит помнить, что существует строгое правило псевдонимов, позволяющее анализировать псевдонимы на основе типов. Каким бы мучительным ни был выбранный маршрут, если вы можете юридически "создать ситуация, когда int* и float* могут существовать одновременно, и оба могут использоваться для загрузки или хранения одной и той же памяти, вы уничтожаете TBAA ". Если вы думаете, что формулировка стандарта каким-то образом позволяет вам это сделать, вы, вероятно, ошибаетесь, но если вы были правы, то все, что вы обнаружили, - это дефект в стандартной формулировке.

¹ Доступ к члену класса является неопределенным (по пропуску), потому что нет фактического объекта PunnerToUInt32. Однако доступ члена класса не является "доступом" в значении строгое правило алиасинга; последнее означает «читать или изменять значение объекта».