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

Фундаментальный факт заключается в следующем: два объекта разных типов могут никогда не иметь псевдонимов в памяти, за некоторыми исключениями (см. Ниже).

Пример

Рассмотрим следующий код:

void sum(double& out, float* in, int count) {
    for(int i = 0; i < count; ++i) {
        out += *in++;
    }
}

Давайте разберем это на локальные регистровые переменные, чтобы более точно смоделировать фактическое выполнение:

void sum(double& out, float* in, int count) {
    for(int i = 0; i < count; ++i) {
        register double out_val = out; // (1)
        register double in_val = *in; // (2)
        register double tmp = out_val + in_val;
        out = tmp; // (3)
        in++;
    }
}

Предположим, что (1), (2) и (3) представляют собой чтение, чтение и запись в память соответственно, что может оказаться очень дорогостоящими операциями в таком жестком внутреннем цикле. Разумной оптимизацией этого цикла была бы следующая:

void sum(double& out, float* in, int count) {
    register double tmp = out; // (1)
    for(int i = 0; i < count; ++i) {
        register double in_val = *in; // (2)
        tmp = tmp + in_val;
        in++;
    }
    out = tmp; // (3)
}

Эта оптимизация снижает количество необходимых операций чтения памяти наполовину, а количество операций записи в память до 1. Это может иметь огромное влияние на производительность кода и является очень важной оптимизацией для всех оптимизирующих компиляторов C и C ++.

Теперь предположим, что у нас нет строгого псевдонима. Предположим, что запись в объект любого типа может повлиять на любой другой объект. Предположим, что запись в double может где-то повлиять на значение числа с плавающей запятой. Это делает вышеупомянутую оптимизацию подозрительной, потому что возможно, что программист на самом деле предназначил для out и in to псевдоним, чтобы результат функции суммы был более сложным и зависел от процесса. Звучит глупо? Даже в этом случае компилятор не может различить «глупый» и «умный» код. Компилятор может различать только правильно сформированный и плохо сформированный код. Если мы разрешаем свободное алиасинг, то компилятор должен быть консервативным в своих оптимизациях и должен выполнять дополнительное хранилище (3) на каждой итерации цикла.

Надеюсь, теперь вы понимаете, почему такой союз или уловка не могут быть законными. Подобные фундаментальные концепции нельзя обойти ловкостью рук.

Исключения из строгого алиасинга

Стандарты C и C ++ делают специальное положение для псевдонима любого типа с char и с любым «связанным типом», который, среди прочего, включает производные и базовые типы и члены, потому что возможность независимо использовать адрес члена класса очень важна. Вы можете найти исчерпывающий список этих положений в этом ответе.

Более того, GCC делает специальные условия для чтения из другого члена союза, чем тот, в который была записана последняя запись. Обратите внимание, что такой тип преобразования через объединение фактически не позволяет вам нарушать псевдонимы. Только один член союза может быть активным одновременно, поэтому, например, даже с GCC следующее поведение будет неопределенным:

union {
    double d;
    float f[2];
};
f[0] = 3.0f;
f[1] = 5.0f;
sum(d, f, 2); // UB: attempt to treat two members of
              // a union as simultaneously active

Обходные пути

Единственный стандартный способ интерпретировать биты одного объекта как биты объекта другого типа - использовать эквивалент memcpy. При этом используется специальное положение для псевдонимов с char объектами, что по сути позволяет вам читать и изменять базовое представление объекта на уровне байтов. Например, следующее является законным и не нарушает строгих правил псевдонима:

int a[2];
double d;
static_assert(sizeof(a) == sizeof(d));
memcpy(a, &d, sizeof(d));

Это семантически эквивалентно следующему коду:

int a[2];
double d;
static_assert(sizeof(a) == sizeof(d));
for(size_t i = 0; i < sizeof(a); ++i)
   ((char*)a)[i] = ((char*)&d)[i];

GCC обеспечивает чтение из неактивного члена объединения, неявно делая его активным. Из документации GCC:

Распространена практика чтения от другого члена профсоюза, чем тот, которому в последний раз писали (так называемая «каламбур»). Даже с -fstrict-aliasing разрешено использование символов при условии, что доступ к памяти осуществляется через тип объединения. Итак, приведенный выше код будет работать должным образом. См. Перечисления объединений структур и реализация битовых полей. Однако этот код не может:

int f() {
    union a_union t;
    int* ip;
    t.d = 3.0;
    ip = &t.i;
    return *ip;
}

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

int f() {
    double d = 3.0;
    return ((union a_union *) &d)->i;
} 

Размещение новое

(Примечание: здесь я использую память, поскольку у меня сейчас нет доступа к стандарту). После того, как вы разместите новый объект в буфере хранилища, время жизни нижележащих объектов хранилища неявно заканчивается. Это похоже на то, что происходит, когда вы пишете члену союза:

union {
    int i;
    float f;
} u;

// No member of u is active. Neither i nor f refer to an lvalue of any type.
u.i = 5;
// The member u.i is now active, and there exists an lvalue (object)
// of type int with the value 5. No float object exists.
u.f = 5.0f;
// The member u.i is no longer active,
// as its lifetime has ended with the assignment.
// The member u.f is now active, and there exists an lvalue (object)
// of type float with the value 5.0f. No int object exists.

Теперь давайте посмотрим на что-то похожее с place-new:

#define MAX_(x, y) ((x) > (y) ? (x) : (y))
// new returns suitably aligned memory
char* buffer = new char[MAX_(sizeof(int), sizeof(float))];
// Currently, only char objects exist in the buffer.
new (buffer) int(5);
// An object of type int has been constructed in the memory pointed to by buffer,
// implicitly ending the lifetime of the underlying storage objects.
new (buffer) float(5.0f);
// An object of type int has been constructed in the memory pointed to by buffer,
// implicitly ending the lifetime of the int object that previously occupied the same memory.

Этот вид неявного завершения срока службы может происходить только для типов с тривиальными конструкторами и деструкторами по очевидным причинам.

Помимо ошибки, когда sizeof(T) > sizeof(U), проблема может заключаться в том, что объединение имеет соответствующее и, возможно, более высокое выравнивание, чем U, из-за T. Если вы не создадите экземпляр этого объединения, чтобы его блок памяти был выровнен (и был достаточно большим!), А затем извлеките член с целевым типом T, в худшем случае он будет тихо сломан.

Например, ошибка выравнивания возникает, если вы выполняете приведение U* в стиле C, где U требует выравнивания 4 байта, к dummy_union*, где dummy_union требует выравнивания до 8 байтов, потому что alignof(T) == 8. После этого вы, возможно, прочитаете член объединения с типом T, выровненным по 4 вместо 8 байтов.

Приведение псевдонима (выравнивание и безопасный размер reinterpret_cast только для POD):

Это предложение явно нарушает строгий псевдоним, но со статическими утверждениями:

///@brief Compile time checked reinterpret_cast where destAlign <= srcAlign && destSize <= srcSize
template<typename _TargetPtrType, typename _ArgType>
inline _TargetPtrType alias_cast(_ArgType* const ptr)
{
    //assert argument alignment at runtime in debug builds
    assert(uintptr_t(ptr) % alignof(_ArgType) == 0);

    typedef typename std::tr1::remove_pointer<_TargetPtrType>::type target_type;
    static_assert(std::tr1::is_pointer<_TargetPtrType>::value && std::tr1::is_pod<target_type>::value, "Target type must be a pointer to POD");
    static_assert(std::tr1::is_pod<_ArgType>::value, "Argument must point to POD");
    static_assert(std::tr1::is_const<_ArgType>::value ? std::tr1::is_const<target_type>::value : true, "const argument must be cast to const target type");
    static_assert(alignof(_ArgType) % alignof(target_type) == 0, "Target alignment must be <= source alignment");
    static_assert(sizeof(_ArgType) >= sizeof(target_type), "Target size must be <= source size");

    //reinterpret cast doesn't remove a const qualifier either
    return reinterpret_cast<_TargetPtrType>(ptr);
}

Использование с аргументом типа указателя (например, стандартные операторы приведения, такие как reinterpret_cast):

int* x = alias_cast<int*>(any_ptr);

Другой подход (позволяет избежать проблем с выравниванием и псевдонимом с помощью временного объединения):

template<typename ReturnType, typename ArgType>
inline ReturnType alias_value(const ArgType& x)
{
    //test argument alignment at runtime in debug builds
    assert(uintptr_t(&x) % alignof(ArgType) == 0);

    static_assert(!std::tr1::is_pointer<ReturnType>::value ? !std::tr1::is_const<ReturnType>::value : true, "Target type can't be a const value type");
    static_assert(std::tr1::is_pod<ReturnType>::value, "Target type must be POD");
    static_assert(std::tr1::is_pod<ArgType>::value, "Argument must be of POD type");

    //assure, that we don't read garbage
    static_assert(sizeof(ReturnType) <= sizeof(ArgType),"Target size must be <= argument size");

    union dummy_union
    {
        ArgType x;
        ReturnType r;
    };

    dummy_union dummy;
    dummy.x = x;

    return dummy.r;
}

Использование:

struct characters
{
    char c[5];
};

//.....

characters chars;

chars.c[0] = 'a';
chars.c[1] = 'b';
chars.c[2] = 'c';
chars.c[3] = 'd';
chars.c[4] = '\0';

int r = alias_value<int>(chars);

Недостатком этого является то, что объединение может потребовать больше памяти, чем фактически необходимо для ReturnType.

Обернутый memcpy (позволяет обойти проблемы с выравниванием и псевдонимом с помощью memcpy):

template<typename ReturnType, typename ArgType>
inline ReturnType alias_value(const ArgType& x)
{
    //assert argument alignment at runtime in debug builds
    assert(uintptr_t(&x) % alignof(ArgType) == 0);

    static_assert(!std::tr1::is_pointer<ReturnType>::value ? !std::tr1::is_const<ReturnType>::value : true, "Target type can't be a const value type");
    static_assert(std::tr1::is_pod<ReturnType>::value, "Target type must be POD");
    static_assert(std::tr1::is_pod<ArgType>::value, "Argument must be of POD type");

    //assure, that we don't read garbage
    static_assert(sizeof(ReturnType) <= sizeof(ArgType),"Target size must be <= argument size");

    ReturnType r;
    memcpy(&r,&x,sizeof(ReturnType));

    return r;
}

Для массивов динамического размера любого типа POD:

template<typename ReturnType, typename ElementType>
ReturnType alias_value(const ElementType* const array,const size_t size)
{
    //assert argument alignment at runtime in debug builds
    assert(uintptr_t(array) % alignof(ElementType) == 0);

    static const size_t min_element_count = (sizeof(ReturnType) / sizeof(ElementType)) + (sizeof(ReturnType) % sizeof(ElementType) != 0 ? 1 : 0);

    static_assert(!std::tr1::is_pointer<ReturnType>::value ? !std::tr1::is_const<ReturnType>::value : true, "Target type can't be a const value type");
    static_assert(std::tr1::is_pod<ReturnType>::value, "Target type must be POD");
    static_assert(std::tr1::is_pod<ElementType>::value, "Array elements must be of POD type");

    //check for minimum element count in array
    if(size < min_element_count)
        throw std::invalid_argument("insufficient array size");

    ReturnType r;
    memcpy(&r,array,sizeof(ReturnType));
    return r;
}

Более эффективные подходы могут выполнять явное невыровненное чтение с помощью встроенных функций, таких как SSE, для извлечения примитивов.

Примеры:

struct sample_struct
{
    char c[4];
    int _aligner;
};

int test(void)
{
    const sample_struct constPOD    = {};
    sample_struct pod               = {};
    const char* str                 = "abcd";

    const int* constIntPtr  = alias_cast<const int*>(&constPOD);
    void* voidPtr           = alias_value<void*>(pod);
    int intValue            = alias_value<int>(str,strlen(str));

    return 0;
}

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

• Утверждения, обеспечивающие преобразование только POD, могут быть улучшены.
• Убраны лишние хелперы шаблонов, теперь используются только трейты tr1
• Статические утверждения для разъяснения и запрета на возвращаемый тип константного значения (не указателя)
• Утверждения времени выполнения для отладочных сборок
• Добавлены квалификаторы const к некоторым аргументам функции
• Другой тип каламбура с использованием memcpy
• Рефакторинг
• Небольшой пример

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

У меня вопрос, на всякий случай, легальна ли эта программа в соответствии со стандартом?

Нет. Использование указанного вами псевдонима может быть неестественным. Написанный вами союз просто перемещает суть псевдонима. Может показаться, что это работает, но эта программа может дать сбой при изменении параметров ЦП, ABI или настроек компилятора.

А если нет, как можно сделать это законным?

Создавайте естественные временные переменные и относитесь к своему хранилищу как к BLOB-объекту памяти (вход и выход из BLOB-объекта в / из временных) или используйте объединение, которое представляет все ваши типы (помните, здесь по одному активному элементу за раз).