Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Приведение типа указателя на элемент структуры
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Страницы: 1, 2
ViKo
Допустим, имеется структура из байтов. Хочу инициализировать сразу 2 байта 16-битовым числом, или сразу 4 байта 32-битовым числом. Привожу указатель к нужному типу.
Код
typedef struct {
  __IO uint8_t A;
  __IO uint8_t B;
  uint16_t RES;
} DEV_t;

  DEV_t Dev;
  DEV_t *pDev = &Dev;

  pDev->A = 0x55;
  pDev->B = 0xAA;
  (uint16_t)pDev->A = 0x3333;
  (uint32_t)pDev->A = 0x01234567;


Код работает. Но Keil выдает предупреждения:
source\Exercises.c(117): warning: #1441-D: nonstandard cast on lvalue
Есть ли способ написать так, чтобы Keil не возмущался?
AHTOXA
*(uint16_t*)&Dev.A = 0x55AA;
ViKo
Цитата(AHTOXA @ Oct 17 2012, 14:11) *
*(uint16_t*)&Dev.A = 0x55AA;

Да, так работает без предупреждений.
И без специально созданного указателя. sm.gif
AHTOXA
Но это хак, работоспособность которого зависит от выравнивания элементов структуры. Надо по крайней мере комментарий про это написать рядышкомsm.gif
ViKo
Цитата(AHTOXA @ Oct 17 2012, 14:27) *
Но это хак, работоспособность которого зависит от выравнивания элементов структуры. Надо по крайней мере комментарий про это написать рядышком

Для того и вводятся резервные места, ну, как в stm32xxx.h
Код
typedef struct
{
  __IO uint32_t DR;         /*!< CRC Data register,             Address offset: 0x00 */
  __IO uint8_t  IDR;        /*!< CRC Independent data register, Address offset: 0x04 */
  uint8_t       RESERVED0;  /*!< Reserved, 0x05                                      */
  uint16_t      RESERVED1;  /*!< Reserved, 0x06                                      */
  __IO uint32_t CR;         /*!< CRC Control register,          Address offset: 0x08 */
} CRC_TypeDef;

По такой аналогии и создавал. Правильное заполнение структуры будет обеспечено, а обращение возможно по любому (невыровненному) адресу. Cortex-M3 же.
_Артём_
Цитата(ViKo @ Oct 17 2012, 14:36) *
Правильное заполнение структуры будет обеспечено, а обращение возможно по любому (невыровненному) адресу. Cortex-M3 же.

А на каких архитектурах при таком обращении возникнут проблемы (и какие)?
ViKo
Цитата(_Артём_ @ Oct 17 2012, 14:58) *
А на каких архитектурах при таком обращении возникнут проблемы (и какие)?

*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.
toweroff
Цитата(ViKo @ Oct 17 2012, 16:06) *
*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.

то есть перед объявлением добавляем __packed?
_Артём_
Цитата(ViKo @ Oct 17 2012, 15:06) *
*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.

И что будет ? HardFault?
ViKo
Цитата(toweroff @ Oct 17 2012, 15:12) *
то есть перед объявлением добавляем __packed?

У меня Cortex-M3, ничего не добавляю, и так хорошо. laughing.gif
_Артём_
Цитата(toweroff @ Oct 17 2012, 15:12) *
то есть перед объявлением добавляем __packed?

Без packed компилятор сам выравняет?
ViKo
Цитата(_Артём_ @ Oct 17 2012, 15:18) *
И что будет ? HardFault?

А то! sm.gif
http://www.google.by/webhp?rlz=1C1GGGE_ruB...745&bih=925

Добавлю. Мне не нужно "утрамбовать" структуру. Наоборот, я описываю в структуре регистры внешнего устройства, в частности, контроллера ЖКИ. С расположением регистров по конкретным адресам. Все, как в упомянутой stm32xxx.h. А обращаться хочу не только по байтам, но и целыми словами.
MrYuran
Цитата(_Артём_ @ Oct 17 2012, 15:58) *
А на каких архитектурах при таком обращении возникнут проблемы (и какие)?

На многих, отличных от 8 бит.
Например, MSP430. По умолчанию выравнивание по границе слова.
Выровненный char займет 2 байта, старший байт 16р инициализатора вместо второго чара улетит в пустоту

Цитата(ViKo @ Oct 17 2012, 16:20) *
я описываю в структуре регистры внешнего устройства, в частности, контроллера ЖКИ.

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

Конечно, не ваш конкретный случай, но все же
ViKo
Цитата(MrYuran @ Oct 17 2012, 15:43) *
Вот в таком случае аттрибут упаковки строго обязателен.
Иначе такие чудеса могут начаться..
Пишешь байт в один регистр, а он улетает в соседний или через несколько

Так заполняю же все адреса подряд! RESERVED вставляю во все дыры! sm.gif
MrYuran
Цитата(ViKo @ Oct 17 2012, 16:46) *
Так заполняю же все адреса подряд! RESERVED вставляю во все дыры! sm.gif

А неважно.
Выровняет по границе машинного слова (16/32/64) - и все ваши RESERVED превратятся в дополнительные 16/32/64р "дыры"
Очень аккуратно нужно действовать, иначе наколоться можно очень неприятно.
ViKo
Цитата(MrYuran @ Oct 17 2012, 15:54) *
А неважно.
Выровняет по границе машинного слова (16/32/64) - и все ваши RESERVED превратятся в дополнительные 16/32/64р "дыры"

Не выравняет. sm.gif Потому что имеется следующий код.
Код
typedef struct {
  __I uint8_t RCR;    //<! Revision Code Register,            0x00
  __I uint8_t DBSR;    //<! Dislpay Buffer Size Register,        0x01
  __I uint8_t CRR;    //<! Configuration Readback Register,        0x02
} ReadOnlyConf_t;    //<! Read-Only Configuration Registers

typedef struct {
  __IO uint8_t MCCR;    //<! Memory Clock Configuration Register,    0x04
  __IO uint8_t PCCR;    //<! Pixel Clock Configuration Register,    0x05
} ClockConf_t;        //<! Clock Configuration Registers
...

#define DPYCTRL_BASE    ((uint32_t)0x6C000000)    //<! Dysplay base address
#define S1DREGS_BASE    DPYCTRL_BASE        //<! S1D13706 registers base

#define READONLYCONF_BASE    S1DREGS_BASE
#define CLOCKCONF_BASE        S1DREGS_BASE + 0x04
#define LOOKUPTABLE_BASE    S1DREGS_BASE + 0x08
...
#define READONLYCONF    ((ReadOnlyConf_t *) READONLYCONF_BASE)
#define CLOCKCONF    ((ClockConf_t *) CLOCKCONF_BASE)
#define LOOKUPTABLE    ((LookUpTable_t *) LOKUPTABLE_BASE)
...

А дальше - обращения по указателям...
_Pasha
Цитата(ViKo @ Oct 17 2012, 14:36) *
Для того и вводятся резервные места, ну, как в stm32xxx.h

Не надо брать пример с индуистского кода. Правильный ответ(причем, всегда)
Код
typedef struct
{
  __IO uint32_t DR;         /*!< CRC Data register,             Address offset: 0x00 */
  union
{
  __IO uint8_t  reg8bit;        /*!< CRC Independent data register, Address offset: 0x04 */
  uint32_t IDR_space;
} IDR;
  __IO uint32_t CR;         /*!< CRC Control register,          Address offset: 0x08 */
} CRC_TypeDef;


Почему у них идеологически не так? Патамушо эти хедеры не для того, чтобы ими пользоваться! sm.gif
_Артём_
Цитата(_Pasha @ Oct 17 2012, 18:18) *
Патамушо эти хедеры не для того, чтобы ими пользоваться! sm.gif

Интересно, а чем же пользоваться?
Самому хидеры на процы делать?
_Pasha
Цитата(_Артём_ @ Oct 17 2012, 18:44) *
Интересно, а чем же пользоваться?
Самому хидеры на процы делать?

Я тут давеча психанул и наваял по означенному выше принципу. Ессно, только структуры, без всяких функций сомнительного сервиса. Но у проекта, который сейчас пилю, уже поезд ушел, тестинг откладывается.
Странно, но LPC такой ненависти не вызывают. Очень странно... sm.gif
Вообще, я там сильно повыделывался - дал битовым полям осмысленные имена... там по-хорошему надо двуязычие, тоже на основе union{}- с сохранением мнемоники и с сохранением смысла... этот момент разрулю - будет тыщи три строк.
И вроде бы взять да и сделать базу в libreoffice base, чтоб генерило то,что надо... блин, лень забадала.
AHTOXA
А в каком случае может не сработать индуистский вариант? Я что-то с наскока не смог добиться, чтобы размер структуры
Код
typedef struct
{
  uint32_t DR;
  uint8_t  IDR;
  uint8_t  spacer;
  uint16_t  spacer2;
  uint32_t CR;
} CRCpeDef;

был не 12. Пробовал все мыслимые варианты -fpack-struct=1, 2, 4, 8, 16.
toweroff
Ух как у меня все это перекликается... и с volatile, и со структурами
Тоже бодаюсь. Чуть позже выложу, если позволите, в этой теме, ибо оооочень похоже
ViKo
Цитата(_Pasha @ Oct 17 2012, 18:18) *
Не надо брать пример с индуистского кода. Правильный ответ(причем, всегда)
...

Я тоже кинулся было править stm32f2xx.h, когда увидел, что не могу одной командой установить и сбросить биты в порту. Из-за
Код
...
  __IO uint16_t BSRRL;    /*!< GPIO port bit set/reset low register,  Address offset: 0x18      */
  __IO uint16_t BSRRH;    /*!< GPIO port bit set/reset high register, Address offset: 0x1A      */
  // __IO uint32_t BSRR;        // GPIO port bit set/reset: 0xRRRRSSSS, Address offset: 0x18
...
} GPIO_TypeDef;

Причем, BSRRL отвечает за установку бита, а BSRRH - за сброс.
Но при пользовании объединениями в имени регистра появляется дополнительное обозначение, которого не хочу.
Поэтому приведение типа указателя для меня более приемлемо.

А насчет библиотеки - функциями не пользуюсь.
А насчет определения битов - #define меня устраивают.
Главное, чтобы код не разбухал.
toweroff
Итак, добавляю sm.gif
есть две области в ARM968E-S
в первой висит 16-битный супресс USB, во второй - NOR Flash

Читается/пишется в первую область только по/из фиксированным адресам
Во вторую - и так, и с инкрементом

оптимизация компилятора в Time и O3

Шины. 1-я с супрессом - 16бит, 2-я - 32 бит

Что-то фигню наблюдаю

Первая область объявлена как
Код
#define        FX2_FIFO2            (*(volatile unsigned int *)(FX2_BASE_ADDR + (0x00UL<<2)))
#define        FX2_FIFO4            (*(volatile unsigned int *)(FX2_BASE_ADDR + (0x02UL<<2)))


вторая - также через volatile, но в своем диапазоне

Доступ к памяти осцилл показывает и, судя по тестам, точно как и надо

А вот данные - не пойми чего
Для пересылки и сокращения доступа к той и другой области памяти попробовал сделать union с тремя полями - U16, U16 и U32
Например, чтение из первой области - в две U16 подряд, потом из U32 - в другую область запись

Шаманство sm.gif Не работает
_Pasha
Цитата(ViKo @ Oct 17 2012, 20:31) *
Я тоже кинулся было править stm32f2xx.h, когда увидел, что не могу одной командой установить и сбросить биты в порту. Из-за[кусь]
Поэтому приведение типа указателя для меня более приемлемо.


Не пойму, кто заремил BSRR, милое дело ©
Код
Inline void pin_set_by_msk(const GPIO_typedef *port, const uint16_t msk, const bool state)
{
  port->BSRR = state?(msk):(msk<<16);
}

компиляется в минимум,- жаль, редко, когда в две-это при интенсивных операциях -инструкции
ViKo
Цитата(_Pasha @ Oct 17 2012, 21:22) *
Не пойму, кто заремил BSRR, милое дело ©

Я же и закомментировал. Сам приписал, сам убрал. Когда возникла дилемма - или писать всегда по 32 бита, или писать, когда надо, по 16-битов. В-общем, надо было иметь и ту, и другую возможность. А union ... уже говорил ... А *(uint32_t *) &GPIOB.BSRRL - то шо надо!
AHTOXA
Цитата(_Pasha @ Oct 18 2012, 00:22) *
Не пойму, кто заремил BSRR, милое дело ©

Дык, индусы, кто ж ещёsm.gif Причём битовые маски оставили как для 32-битного BSRR. (Это для F2xx.)
Я всё же такого не стерпел, и переписал это определение.
_Pasha, так в каком случае индуистский подход с ручными отступами в структурах может привести к неправильному результату? Или здесь речь чисто об эстетике? sm.gif
toweroff
Админы, я так понимаю, здесь свой колхоз sm.gif
я это все отправлю а "ARM, 32bit", здесь уберите, мешает всем
ViKo
Цитата(_Pasha @ Oct 17 2012, 21:22) *
port->BSRR = state?(msk):(msk<<16);
...
компиляется в минимум,- жаль, редко, когда в две-это при интенсивных операциях -инструкции

Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.
_Pasha
Цитата(AHTOXA @ Oct 17 2012, 21:35) *
_Pasha, так в каком случае индуистский подход с ручными отступами в структурах может привести к неправильному результату? Или здесь речь чисто об эстетике? sm.gif

Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.
Хотя, странно -fpack-struct=8 должен бы, как представляется...
Я только выразил недоумение по поводу головоломок там, где их быть не должно, при передвижении на круглых колесах, тсз.sm.gif
AHTOXA
Цитата(ViKo @ Oct 18 2012, 00:47) *
Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.

Вообще-то для этого есть ODR sm.gif
_Pasha
Цитата(ViKo @ Oct 17 2012, 21:47) *
Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.

wacko.gif Да хоть 100! Из 16-ти
ViKo
Цитата(AHTOXA @ Oct 17 2012, 21:52) *
Вообще-то для этого есть ODR sm.gif

Точно! Что-то я упустил его из виду! Вот спасибо! sm.gif Пойду поправлю нафиг. Еще один шаг к совершенству.
А он у них (индусов) - тоже, 32-х разрядный! sm.gif
Кстати, если про BSRR в Ref Manual написано "These bits are write-only and can be accessed in word, half-word or byte mode", то про доступ к ODR - молчок. Можно ли туда послать 16 битовое число?

Про IDR написано конкретно: These bits are read-only and can be accessed in word mode only.
AHTOXA
Цитата(_Pasha @ Oct 18 2012, 00:50) *
Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.

А в чём тогда "правильность" кода с union-ами?
Цитата(_Pasha @ Oct 18 2012, 00:50) *
Хотя, странно -fpack-struct=8 должен бы, как представляется...

Как я понял, -fpack-struct[=x] может только сильнее упаковать структуру. Проредить её может __attribute__ ((aligned (x))). Но его нужно явно указывать для члена структуры, случайно так не сделать.
_Pasha
Цитата(AHTOXA @ Oct 17 2012, 21:59) *
А в чём тогда "правильность" кода с union-ами?

В данном случае - чисто йуридически
Цитата
warning: #1441-D: nonstandard cast on lvalue

Где оно выползет боком - фантазии не хватает представить.
Для АРМов сумасшедшие компиляторы а-ля CodeVision для АВРок - существуют? sm.gif
Если бы были - там бы и повылезло.
ViKo
Цитата(_Pasha @ Oct 17 2012, 22:17) *
В данном случае - чисто йуридически
Где оно выползет боком - фантазии не хватает представить.

Нигде. Только сон будет менее спокойным.
P.S. Видно по результатам компиляции - все нормально.
Дмитриос
Цитата(_Pasha @ Oct 17 2012, 20:21) *
Я тут давеча психанул и наваял по означенному выше принципу. Ессно, только структуры, без всяких функций сомнительного сервиса. Но у проекта, который сейчас пилю, уже поезд ушел, тестинг откладывается.

Простите а вот под какой контроллер вы так сделали?
_Pasha
Цитата(Дмитриос @ Oct 17 2012, 23:22) *
Простите а вот под какой контроллер вы так сделали?

STM32f100
Но, сделал - и пожалел. Надо сразу базу данных заводить и оттуда генерить. Писанина - плохой стиль.
Дмитриос
Цитата(_Pasha @ Oct 18 2012, 00:39) *
STM32f100
Но, сделал - и пожалел. Надо сразу базу данных заводить и оттуда генерить. Писанина - плохой стиль.

А разве производитель CMSIS ные либы со структурами не создаёт для регистров данного контроллера или у Вас свои какие-то структуры?
_Pasha
Цитата(Дмитриос @ Oct 17 2012, 23:53) *
А разве производитель CMSIS ные либы со структурами не создаёт для регистров данного контроллера или у Вас свои какие-то структуры?

Они обходят стороной битовые поля, имея ввиду, что применение их в общеупотребительном смысле неэффективно. Я так думаю, зря.
AHTOXA
Цитата(_Pasha @ Oct 18 2012, 01:17) *
В данном случае - чисто йуридически

Да нет же, я не об этом! sm.gif Там ViKo просто не то не к тому привёл.
Я вот о чём. Чем ваш вариант
Код
typedef struct
{
  __IO uint32_t DR;
  union
{
  __IO uint8_t  reg8bit;
  uint32_t IDR_space;
} IDR;
  __IO uint32_t CR;
} CRC_TypeDef;

лучше индуистского варианта
Код
typedef struct
{
  __IO uint32_t DR;
  __IO uint8_t  reg8bit;
  __IO uint8_t  spacer;
  __IO uint16_t  spacer2;
  __IO uint32_t CR;
} CRC_TypeDef;

?
MrYuran
Цитата(_Pasha @ Oct 17 2012, 22:50) *
Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.

Сталкивался, не то слово.
MSPGCC образца 2008 года и iostructures.h
Причем, там явно было указано __attribute__ (("packed")) под каждой структурой, однако ж..
После серии необъяснимых чудес пришлось лезть в листинг и сверять адреса регистров.
Помогло только -fpack-struct, когда все структуры принудительно упаковывались.
После того все переписал на макросы Волкова.
Конечно, не так красиво, зато работает железно.

Хотя, сейчас поглядел...
Код
#if defined(__MSP430_HAS_PORT0__)
struct port0_t {
  ioregister_t    in;    /* Input */
  ioregister_t    out;    /* Output */
  ioregister_t    dir;    /* Direction */
  ioregister_t    ifg;    /* Interrupt Flag */
  ioregister_t    ies;    /* Interrupt Edge Select */
  ioregister_t    ie;    /* Interrupt Enable */
};

__MSP430_EXTERN__ struct port0_t port0 asm("0x0010");
#endif


Здесь почему-то упаковки нет.. Странно..
Это в корне меняет дело, а я на компилятор грешил.
Но суть то этого не меняется. Автоматически выровненная структура "прореживается" и все адреса сползают.
AHTOXA
Цитата(MrYuran @ Oct 18 2012, 11:12) *
Это в корне меняет дело
...
Но суть то этого не меняется.

Жжоте biggrin.gif
Тем не менее. test.c:
Код
typedef struct
{
    unsigned char a;
    unsigned char b;
}str;

char zzz[1 - 2*(sizeof(str) != 2)];


gcc -c test.c - порядок.
avr-gcc -c test.c - порядок.
arm-kgp-gcc -c test.c - порядок.
arm-none-eabi-gcc -c test.c - порядок.
msp430-gcc -c test.c - порядок.

Что надо сделать, чтобы "проредило"?
MrYuran
Цитата(AHTOXA @ Oct 18 2012, 10:14) *
Что надо сделать, чтобы "проредило"?

Я не знаю, что надо сделать, но точно знаю теперь, чего не надо..
Не надо использовать такие структуры без принудительной упаковки, во избежание.
Мне совершенно было не смешно, когда port1.out.pin3 = 1 махал битами в регистре dir вместо out (а это ещё надо было найти)
Палыч
Цитата(AHTOXA @ Oct 18 2012, 10:14) *
Что надо сделать, чтобы "проредило"?

Вставить #pragma pack(n) или указать транслятору -fpack-struct=n cо значением n отличным от 1.
К сожалению, в документации на gcc нигде нет упоминания: какое значение n (величина выравнивания) принято "по-умолчанию"...
_Pasha
Цитата(AHTOXA @ Oct 18 2012, 06:39) *
Да нет же, я не об этом! sm.gif Там ViKo просто не то не к тому привёл.

Дык я это "не то не к тому" унаследовал, пытаясь сказать, что сабжевое приведение - лишняя суета и потенциальный источник проблем. Ну не может быть, чтобы хаки и нормальные построения вели себя везде одинаково!
AHTOXA
Цитата(MrYuran @ Oct 18 2012, 12:25) *
Я не знаю, что надо сделать, но точно знаю теперь, чего не надо..
Не надо использовать такие структуры без принудительной упаковки, во избежание.
Мне совершенно было не смешно, когда port1.out.pin3 = 1 махал битами в регистре dir вместо out (а это ещё надо было найти)
Скорее всего был локальный глюк какой-то конкретной версии mspgcc. Хотя принудительная упаковка - дело несложное, можно и её добавить, для пущей уверенности.

Цитата(Палыч @ Oct 18 2012, 12:55) *
Вставить #pragma pack(n) или указать транслятору -fpack-struct=n cо значением n отличным от 1.
К сожалению, в документации на gcc нигде нет упоминания: какое значение n (величина выравнивания) принято "по-умолчанию"...

Нет, ничего из этого не увеличивает размер структуры. Проверил и с #pragma pack(x), и с -fpack-struct=x (x={4,8,16,32}), и с ними обоими одновременно.
До кучи проверил __attribute__ ((packed)) и __attribute__ ((aligned (x))) для типа.
Размер структуры равен 2, как я не извращался sm.gif
Единственный вариант, который изменил размер, был вот такой:
Код
typedef struct
{
    unsigned char a __attribute__ ((aligned (8)));
    unsigned char b __attribute__ ((aligned (8)));
}str;

Но этот вариант не страшен, потому что явно указывать alignment там, где он не нужен, мы не будем.

Цитата(_Pasha @ Oct 18 2012, 13:44) *
Дык я это "не то не к тому" унаследовал, пытаясь сказать, что сабжевое приведение - лишняя суета и потенциальный источник проблем.

А, вон оно что! Теперь понялsm.gif
ViKo
Цитата(_Pasha @ Oct 18 2012, 10:44) *
Ну не может быть, чтобы хаки и нормальные построения вели себя везде одинаково!

Приведение типов - не хак. А осознанная необходимость. Я не с дырами борюсь, их у меня нет. А хочу писать не только 8-битовыми словами, но и 16-битовыми, 32-битовыми. Cortex-M это позволяет делать, начиная с любого адреса. Тем более, регистры микроконтроллера (или контроллера ЖКИ, который использую) и так выровнены по адресам.
Приведение типов указателя - обычное дело.
Палыч
Цитата(AHTOXA @ Oct 18 2012, 11:49) *
Нет, ничего из этого не увеличивает размер структуры.
А теперь попробуйте проверить на такой структуре:
Код
typedef struct
{
    unsigned char a;
    unsigned int  b;
    unsigned char c;
}str;
XVR
Вообще то компиляторы упаковывают структуры не от их [компилятора] большого желания, а от требования выполнить ограничения по выравниванию для полей этих самых структур. Так что, если у вас в структуре нет полей с требованиями по выравниванию (например у вас там все char) - то ничего выравниваться и не будет. А вот если есть - то перед этим полем может появится дыра, и вся структура в целом получит ограничение по выравниванию, как для этого поля (что в свою очередь может добавить дыру и в конце структуры)
Например (предполагаю требования по выравниванию на размер поля):
Код
struct {
int8_t f8;
int16_t f16;
int32_t f32;
int8_t  f8_2;
};
// Превратится в
struct {
int8_t f8;
int   :8; // Выравнивание для f16 на границу 2х байтов
int16_t f16;
int  :16; // Выравнивание для f32 на границу 4х байтов
int32_t f32;
int8_t f8_2;
int :24; // Выравнивание размера всей структуры, как требует поле f32
};
ViKo
Цитата(XVR @ Oct 18 2012, 11:23) *
int :16; // Выравнивание для f32 на границу 4х байтов

лишнее
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.