Приведение структуры к uint32_t

@dopleref · Регистрация: 15.12.2015

Студворк — интернет-сервис помощи студентам

Добрый день!
Есть переменная пользовательского типа, представляющая собой
структуру размером 32 байта, хочу получить ее значение в переменной типа uint32_t,
как это лучше сделать?

Структура

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
typedef struct
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
    uint32_t interface  : 3;
    uint32_t number     : 8;
    uint32_t command    : 9;
    uint32_t type       : 9;
    uint32_t nodata     : 3;
#elif __BYTE_ORDER == __BIG_ENDIAN
    uint32_t nodata     : 3;
    uint32_t type       : 9;
    uint32_t command    : 9;
    uint32_t number     : 8;
    uint32_t interface  : 3;
#else
#error "__BYTE_ORDER not defined"
#endif
}
abtci_protocol_header;

Хочу сделать что то типа такого (пример понятное дело не работает):

C++
1
2
abtci_protocol_header header;
uint32_t id = (uint32_t) header;

@DrOffset · 24.08.2017, 14:57

dopleref,

C++
1
2
3
4
abtci_protocol_header header;
uint32_t id;
static_assert(sizeof header == sizeof id, "sizes not the same");
std::memcpy(&id, &header, sizeof id);

@Bretbas · 24.08.2017, 14:57

dopleref, Я сам не делал такого, но думаю, нужно двигаться в сторону перегрузки преобразования пользовательских типов

@TRam_ · 24.08.2017, 15:14

Сообщение от dopleref

структуру размером 32 байта

32 бита?

@dopleref · 25.08.2017, 08:19 **[ТС]**

Добавлено через 10 секунд

Сообщение от TRam_

32 бита?

Да 32 бита, извините глупая ошибка

Сообщение от DrOffset

C++
1
std::memcpy(&id, &header, sizeof id);

Спасибо, буду использовать Ваш вариант.

Сообщение от Bretbas

нужно двигаться в сторону перегрузки преобразования пользовательских типов

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

Хотел просто как нибудь 'скастовать', но похоже без memcpy или оператора приведения типа тут не обойтись.
Спасибо большое за ответы!

@dopleref · 28.08.2017, 10:37 **[ТС]**

Если кому-то интересно, нашел еще такой вариант используя 'кастование':

C++
1
uint32_t v = *reinterpret_cast<uint32_t*>(&header);

@Alex5 · 28.08.2017, 11:26

Сообщение от dopleref

не могу менять код определяющий используемую структуру

Можно использовать объединения:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
union U
{
    abtci_protocol_header h;
    int n;
};
 
    U u ={};
    int num;
 
    u.h.nodata = 1;
    num = u.n;  // 0x20000000
 
    u.h.nodata = 2;
    num = u.n;  // 0x40000000
 
    u.h.nodata = 4;
    num = u.n;  // 0x80000000

Croessmah · 28.08.2017, 14:47

Сообщение от dopleref

Если кому-то интересно, нашел еще такой вариант используя 'кастование':

Так лучше не надо.
Делайте через memcpy,
как посоветовал DrOffset.

Alex5, такой подход - ub.

@mishelle92 · 28.08.2017, 20:31

Сообщение от Croessmah

Так лучше не надо.
Делайте через memcpy,
как посоветовал DrOffset.

А можно подробней? Правильно понимаю, что это UB? Т.е. разыменование преобразованного указателя.

Сообщение от Croessmah

Alex5, такой подход - ub.

И тут поясните пожалуйста, почему UB.

Croessmah · 28.08.2017, 21:05

Сообщение от mishelle92

А можно подробней?

Сообщение от mishelle92

И тут поясните пожалуйста

Приведение указателя базового типа

@mishelle92 · 28.08.2017, 21:29

Croessmah, и все же. Хочу разобраться.

1. Чем reinterpret_cast хуже memcpy (будем считать, что sizeof(uint32_t) == sizeof(abtci_protocol_header))?
2. Про union. UB - запись в одно поле и чтение из другого?

@mishelle92 · 29.08.2017, 23:17

Мне кажется я видел достаточно много кода с применением union как в сообщении.

Добавлено через 9 минут

Сообщение от mishelle92

Мне кажется я видел достаточно много кода с применением union как в сообщении.

Видимо перенесенный из C код. А reinterpret_cast плох тем, что из-за strict aliasing может быть UB.

@hoggy · 29.08.2017, 23:23

Сообщение от mishelle92

А можно подробней? Правильно понимаю, что это UB? Т.е. разыменование преобразованного указателя.

https://habrahabr.ru/post/114117/

Сообщение от mishelle92

Про union. UB - запись в одно поле и чтение из другого?

да.

@mishelle92 · 29.08.2017, 23:28

Сообщение от hoggy

https://habrahabr.ru/post/114117/

Да, читал, спасибо. Потому и спросил, чтоб удостоверится. В той же статье правда union и предлагают использовать (пример SwapWords) - несостыковка.

@hoggy · 29.08.2017, 23:32

Сообщение от mishelle92

В той же статье правда union и предлагают использовать (пример SwapWords) - несостыковка.

с оговоркой, что это UB

@mishelle92 · 29.08.2017, 23:33

Сообщение от hoggy

с оговоркой, что это UB

Как-то упустил из виду. Теперь всё встало на свои места.

@DrOffset · 30.08.2017, 00:30

mishelle92, читать из неактивного члена дозволяется если хранящиеся объекты layout-compatible.
9.5/1

In a union, at most one of the non-static data members can be active at any time, that is, the value of at
most one of the non-static data members can be stored in a union at any time. [ Note: One special guarantee
is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout
structs that share a common initial sequence (9.2), and if an object of this standard-layout union type
contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of
standard-layout struct members; see 9.2. —end note ]

В статье, однако, нет никакой оговорки насчет union (оно и понятно - статья совсем про другое), оговорка там про касты через указатели (т.е. через упомянутый выше reinterpret_cast).
Тем не менее, прием c union довольно прочно укоренился среди программистов и компиляторы, как правило, не мешают ожидаемомоу поведению. С точки же зрения теории тут не все так однозначно. Почитать советую правило 97 из книжки Стандарты программирования на С++ и вот этот пост на stackoverflow (за разумное время написать лучше вряд ли будет можно).

Про reinterpret_cast и strict aliasing есть еще вот такая статья: http://dbp-consulting.com/tuto... asing.html, почитай, она хорошо раскрывает в том числе и способ решения через union.

Но еще важное, о чем тут не сказали, alignment для bit-field - implementation defined, padding для bit-field - тоже.
9.6/1

Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined.

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

В общем, что я хочу сказать: не надо пользоваться сомнительными способами, сознательно закладывать в код не очень чистые приемы. И если ты сходу не сможешь вспомнить все ограничения и оговорки, которые накладывают вышеупомянутые "хакерские" способы, то и не стоит их применять.
memcpy для известного на этапе компиляции размера на современных компиляторах превращается в одну или две инструкции. Можно сравнить: https://godbolt.org/g/k4PtzL. Никакой потери эффективности не будет в большинстве случаев, при полном сохранении корректности кода. Без оговорок и спорах об UB.

@Alex5 · 30.08.2017, 11:49

Сообщение от Croessmah

такой подход - ub.

Croessmah, Вы имеете в виду пункт 9.5 стандарта или что-то другое?

Сообщение от DrOffset

the value of at most one of the non-static data members can be stored in a union at any time.

Croessmah, DrOffset, "only one can be stored" - "только одно может храниться". Здесь нет запрещения читать из другого поля.

C++
1
2
3
4
5
6
7
8
union U{
  int a, b, c;
} u;
u.a = 100; u.b = 200; u.c = 300;  // только одно значение   can be stored 
// это не мешает нам прочитать любой член объединения
cout << u.a << endl;  // 300 
cout << u.b << endl;  // 300 
cout << u.c << endl;  // 300

Добавлено через 30 минут

Сообщение от DrOffset

не надо пользоваться сомнительными способами, ...
memcpy ...DrOffset, при полном сохранении корректности кода

DrOffset, с учетом сказанного о bit-field, сомнительность всех трех способов (memcpy, reinterpret_cast, union) одинакова.

Может кто-нибудь привести пример компилятора, на котором значения n1, n2, n3 будут различны?

C++
1
2
3
4
5
6
7
8
9
union U{
  int a, b, c;
} u;
u.a = 100; u.b = 200; u.c = 300;  
 
int n1, n2, n3; 
n1 = u.a;
memcpy( & n2, &u, sizeof(int) );
n3 = * reinterpret_cast<int*>(&u);

Assembler
1
2
3
4
5
6
7
8
9
10
11
12
13
14
n1 = u.a;
011D16F3 8B 45 F8         mov         eax,dword ptr [u] 
011D16F6 89 45 EC         mov         dword ptr [n1],eax 
memcpy( & n2, &u, sizeof(int) );
011D16F9 6A 04            push        4    
011D16FB 8D 45 F8         lea         eax,[u] 
011D16FE 50               push        eax  
011D16FF 8D 4D E0         lea         ecx,[n2] 
011D1702 51               push        ecx  
011D1703 E8 01 FA FF FF   call        @ILT+260(_memcpy) (11D1109h) 
011D1708 83 C4 0C         add         esp,0Ch 
n3 = * reinterpret_cast<int*>(&u);
011D170B 8B 45 F8         mov         eax,dword ptr [u] 
011D170E 89 45 D4         mov         dword ptr [n3],eax

@DrOffset · 30.08.2017, 12:09

Alex5, твой пример как раз попадает под "One special guarantee", т.е. это точно легальный код.
Что касается разных типов, то тут все сложнее.
Да, стандарт явно не пишет, что, дескать такое использование union - undefined behaviour, но и при этом и не регламентирует это поведение (за исключением специально оговоренных layout-compatible типов). Т.е. стандарт дает гарантии насчет одинаковых типов (см. определение common initial sequence), но ничего не говорит насчет разных. Можно привести контр-пример:

C++
1
2
3
4
5
6
7
union U{
  int a;
  double c;
} u;
 
u.a = 100;
// что будет при чтении с?

Очевидно, что поведение не определено, т.к. разрядность и layout хранимых типов несовместимы.
В более простых случаях, когда мы можем implementation-defined способами обеспечить совместимость типов - это будет работать (например, как в твоем примере на первой странице). Но это не означает автоматически легальность. Это означает, что мы для нашей реализации все учли и получили (для нашей реализации) предсказуемое поведение. Да, мы молодцы и это работает. Но стандарт на это гарантий нам не дал.

И еще, прошу, прежде чем продолжать, изучить все материалы, ссылки на которые я дал. Возможно это снимет часть вопросов.

Добавлено через 3 минуты

Сообщение от Alex5

DrOffset, с учетом сказанного о bit-field, сомнительность всех трех способов (memcpy, reinterpret_cast, union) одинакова.

С точки зрения работы с bit-field - да. Поэтому я и написал, что переносимый способ - это делать упаковку бит сдвигами.
Однако дискуссия уже перешла в другую плоскость, где отдельно обсуждаются собственные проблемы reinterpret_cast, и отдельно - собственные проблемы union. Это надо учитывать. А вот memcpy собственных проблем не имеет (ну, кроме потенциального оверхеда на вызов функции).

@УГнетатель · 30.08.2017, 14:09

Сообщение от Alex5

"only one can be stored" - "только одно может храниться". Здесь нет запрещения читать из другого поля.

А как можно читать из поля, которое не хранится? (за искл. исключений для полей из common initial sequence для layout-compatible структур).

Сообщение от DrOffset

пример как раз попадает под "One special guarantee", т.е. это точно легальный код.

Guarantee даётся для структур в union-е. А int — не структура.
Можно ли относиться к типу T как к структуре с единственным полем типа T, по аналогии с тем, как стандарт в некоторых аспектах позволяет относиться к переменным не-массивам как к массивам с одним элементом?

Новые блоги и статьи Все статьи Все блоги /
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .
Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .

@Bretbas Каждому свое 533 / 219 / 81 Регистрация: 05.08.2013 Сообщений: 1,614
	24.08.2017, 14:57
	dopleref, Я сам не делал такого, но думаю, нужно двигаться в сторону перегрузки преобразования пользовательских типов 1

@mishelle92 73 / 69 / 38 Регистрация: 09.10.2012 Сообщений: 238
	28.08.2017, 21:29
	Croessmah, и все же. Хочу разобраться. 1. Чем reinterpret_cast хуже memcpy (будем считать, что sizeof(uint32_t) == sizeof(abtci_protocol_header))? 2. Про union. UB - запись в одно поле и чтение из другого? 0

Приведение структуры к uint32_t

Решение