Объединения, псевдонимы и подбор текста на практике: что работает, а что нет?

Псевдонимы можно понимать буквально: это когда два разных выражения относятся к одному и тому же объекту. Каламбур — это «каламбур» типа, то есть использование объекта одного типа в качестве другого типа.

Формально, каламбур — это неопределенное поведение, за редким исключением. Обычно это случается, когда вы небрежно возитесь с битами

int mantissa(float f)
{
    return (int&)f & 0x7FFFFF;    // Accessing a float as if it's an int
}

Исключения (упрощенные)

• Доступ к целым числам как к их беззнаковым / подписанным аналогам
• Доступ к чему угодно как char, unsigned char или std::byte

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

void transform(float* dst, const int* src, int n)
{
    for(int i = 0; i < n; i++)
        dst[i] = src[i];    // Can be unrolled and use vector instructions
                            // If dst and src alias the results would be wrong
}

Что говорит gcc, так это то, что он немного смягчает правила и позволяет набирать типы через объединения, даже если стандарт не требует, чтобы

union {
    int64_t num;
    struct {
        int32_t hi, lo;
    } parts;
} u = {42};
u.parts.hi = 420;

Это тип-каламбур, который гарантирует gcc. Другие корпуса могут показаться работоспособными, но однажды они могут быть тихо сломаны.

Я думаю, что ваш пример не работает в том смысле, что расположение битовых полей в этой структуре само определяется реализацией. Плохое определение битовых полей в C — одна из тех действительно раздражающих вещей, которые, вероятно, уже слишком поздно исправить. Типа каламбур подходит (по крайней мере, в GCC), но битовое поле может делать то, что вы ожидаете, а может и не делать. — person L.C.; 19.02.2019

@DanMills Fair, но я не мог придумать красивый и легкий каламбур из головы. Я подумал, что если я хочу показать то, что практически работает, то могу пойти до конца. — person L.C.; 19.02.2019

@Passer Один довольно распространенный пример — это что-то вроде union { long long x; struct { unsigned low, high } } (или то же самое, но с unsigned[2], вы уловили идею). — person L.C.; 19.02.2019

В контекстах, отличных от интерпретации gcc / clang правила строгого псевдонима, термин псевдоним не будет использоваться для описания ситуаций, в которых одна ссылка используется для получения другой, а новая ссылка используется для доступа к объекту, а затем отбрасывается до объект используется любым другим способом. — person L.C.; 19.02.2019

@supercat Я не совсем понимаю вашу точку зрения. Псевдоним — это не интерпретируемое значение, это английское слово. Строгий псевдоним как фраза не существует в стандарте C ++, но обычно относится к [expr.lval]. — person L.C.; 20.02.2019

@PasserBy: тот факт, что две ссылки идентифицируют один и тот же объект в непересекающиеся моменты времени, не подразумевает псевдонима. Также не используется тот факт, что ссылка используется для получения другой ссылки, которая немедленно используется для доступа к объектам. Это оба ожидаемых шаблонов доступа, в то время как термин «псевдонимы» относится к ситуациям, когда можно было видеть, что время жизни ссылок перекрывается, не имея возможности увидеть какие-либо отношения между ними. — person L.C.; 20.02.2019

В ANSI C (AKA C89) у вас есть (раздел 3.3.2.3 Элементы структуры и объединения):

если к члену объекта объединения осуществляется доступ после того, как значение было сохранено в другом члене объекта, поведение определяется реализацией

В C99 у вас есть (раздел 6.5.2.3 Элементы структуры и объединения):

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

IOW, перфорирование типов на основе объединения разрешено в C, хотя фактическая семантика может отличаться в зависимости от поддерживаемого языкового стандарта (обратите внимание, что семантика C99 уже, чем C89 , определяемая реализацией).

В C99 у вас также есть (раздел 6.5 Выражения):

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

— тип, совместимый с эффективным типом объекта,

— квалифицированная версия типа, совместимого с действующим типом объекта,

— тип, который представляет собой знаковый или беззнаковый тип, соответствующий действующему типу объекта,

— тип, который является типом со знаком или без знака, соответствующим квалифицированной версии действующего типа объекта,

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

— символьный тип.

И есть раздел (6.2.7 Совместимый тип и составной тип) в C99, который описывает совместимые типы:

Два типа имеют совместимый тип, если их типы совпадают. Дополнительные правила для определения совместимости двух типов описаны в 6.7.2 для спецификаторов типов, в 6.7.3 для квалификаторов типов и в 6.7.5 для деклараторов. …

И затем (6.7.5.1 деклараторы указателя):

Чтобы два типа указателей были совместимыми, оба должны иметь одинаковую квалификацию и оба должны быть указателями на совместимые типы.

Немного упрощая это, это означает, что в C с помощью указателя вы можете получить доступ к целым числам со знаком как целым числам без знака (и наоборот), и вы можете получить доступ к отдельным символам в чем угодно. Все остальное будет равносильно нарушению псевдонима.

Вы можете найти аналогичный язык в различных версиях стандарта C ++. Однако, насколько я понимаю, в C ++ 03 и C ++ 11 каламбур на основе объединения явно не разрешен (в отличие от C).

УФ: этот ответ проясняет концепцию совместимых типов (я полагаю, это то, что они подразумевают под подобными типами). Я полностью согласен, что это явно не разрешено стандартом, но в некоторых случаях это работает с GCC. Это одна из ситуаций, когда «явно не разрешено» не означает «запрещено». — person L.C.; 19.02.2019

@ L.C. это не значит, что он не сломается внезапно на другом компиляторе, архитектуре, ОС или даже на новой версии компилятора. — person L.C.; 19.02.2019

Вы правы, все понятно … но создание кода с открытым исходным кодом, гибкого и переносимого и т. Д. Не всегда является основной целью. Это не элегантно, это не очень хорошая практика, но иногда просто нужен двоичный файл, который работает на текущей машине / ОС … поэтому, если компилятор создает правильный код, который делает то, что ожидается … почему бы и нет! — person L.C.; 19.02.2019

Я думаю, что было бы хорошо добавить дополнительный ответ просто потому, что, когда я задавал вопрос, я не знал, как удовлетворить свои потребности без использования UNION: я упрямо использовал его, потому что он, казалось, отвечал именно моим потребностям.

Хороший способ выполнить каламбур типов и избежать возможных последствий неопределенного поведения (в зависимости от компилятора и других настроек окружения) — использовать std :: memcpy и копировать байты памяти из одного типа в другой. Это объясняется, например, здесь и здесь.

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

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