Ну тут можно использовать стандартную фичу С99 _Pragma() внутри #define. Но IMHO главное на что надо обратить внимание это на тормознутый код при обращении через указатель к 16 и 32 битным полям именно по этому pack в данном случае лучше не использовать.

Бессмысленность какая-то НУ ЗАЧЕМ ИМЕТЬ некое абстрактное число, которое, Вы называете "КОЛИЧЕСТВО БАЙТ", если оно НЕ СООТВЕТСТВУЕТ реальному состоянию дел? sizeof() возвращает именно количество байт занимаемое структурой. Для чего понадобилось-бы число байт которое-бы занимала-бы структура если-бы была-бы упакована я ума не приложу - откройте тайну! Заодно еще один вопрос - а причем тут тема EWARM 5.10 ?

С программе больше 70 различных структур данных, которые в итоге, в зависимости от состояния программы, отправляются одной и той же функцией по RS232. Причем данные в структурах периодически меняются, но всегда выровнены по DWORD, за исключением байтовых концовок.
Причем содержимое(размер) структур колеблется при написании программы. Есть функция, которая умеет тупо передавать массив байт. При отправке указатель на структуру приводится к BYTE*, и еще указывается длина (все как обычно). Вот и хотел избавить себя от рутинной работы измерения размера структуры каждый раз при ее изменении и прописывания ее размера через константу в #define. Но как выяснилось, такое сделать не получается в принципе

Ну и чем, этой функции передачи, простите, поможет знание того, что в структре есть XX байтов, которые нужно выковырять и переслать? Все равно БЕЗ ЗНАНИЯ СТРУКТУРЫ только по XX функция передачи не сможет из извлечь. А если она знает структуру, то на кой ей сдалось какое-то число байтов живописно в этой структуре расположенных. Посему вопрос остался открытым - зачем?
В таких случаях несмотря на поигрыш в быстродействии идут на паковку структур. Получается просто и беспроблемно принимать-передавать. В конце концов все не так и срашно c паковкой - Вы ведь работаете со строками, например?

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

Я не хочу ковырять байты, для этого пустоты ликвидировал,
уже писал, что все структуры выровнены, например так:

struct MyStr
{
BYTE P1;
BYTE P2;
WORD Z1;
DWORD Z2;
DWORD Z3;
BYTE K1;
}

Вот эта структура выровнена, потому что в ней все данные находятся в нужных местах и дыр в ней нет. Длина ее 13 байт, а область памяти, которую выделит компановщик, будет 16 байт. Передавать надо по GPRS, поэтому плодить лишьний трафик не выгодно. Собственно мне не хотелось еще плодить дополнительные директивы для определения длины каждой структуры. Которые потом надо еще не забыть поменять.

Сообщение отредактировал Vitaliy_ARM - Mar 18 2008, 19:05

Дыры в ней ЕСТЬ о чем Вам и говорит sizeof(). Хотите получить 13 - #pragma pack Вам в помощь.

Выход конечно есть , обьявляете массив из 13 байт, а далее через приведение типов. Но в будущем если понадобится изменить структру или она выростит или еще что то, проблемы гарантированы.

Выход это официальная, четкая, ясная, переносимая и т.д...паковка структур а не построения предположений о размещении элементов в неупакованной структуре и ее размерах. Ну получили 16 байт, а получить на законных основаниях 24 не хотите?

Обьясните ?

Что объяснить? Что компилятор имеет право выделять каждой из переменных неупакованной структуры, например, по 32 бита?

1. Мы ведь в ветке IAR, значит речь идет о нем, следовательно читаем как он пакует структуры.
2. Я еще не видел в жизни компилятора который для структуры из 4 байт выделил бы 16 байт памяти
3. Выравнивание структуры подрузумевает размещение переменных согластно их типу по нужному для этого типа адресу + учитывается архитектура ядра (не все ядра умеют работать с байтами, но это уже отдельный случай), а не просто создание размера струкруры кратной кокогото размера.

Вывод НЕ ИМЕЕТ такого права, если конечно потдерживает стандарт.

Тогда пречитайте свой-же п.3, (только до того места, когда началась явная отсебятина) - "Выравнивание структуры подрузумевает размещение переменных согластно их типу по нужному для этого типа адресу + учитывается архитектура ядра".
В который (последний, ибо утомило ) раз спрашиваю, зачем отдавая паковку на опкуп компилятору пытатся после этого перехитрить и компилятор, и себя, и сетовать на разработчиков языка, если предусмотрено УПРАВЛЕНИЕ паковкой структур???

Производительность !. Код с упакованными структурами меделеннее и более емкий. так как компилятор начинает с структурой по байтово работать.

Расмотрим такой вариант.

Есть некий интерфейс скажем UART. Он умеет отсылать массив данных.

Прототип


Чисто гипотетически выдумаем протокол.
Структура протокола

u8_t prot_type;
u8_t paket_len;
u16_t cmd;
u32_t parametrs;
u16_t crc;
u8_t data[x]; //где x это поле данных которое имеет переменную длинну указанную в paket_len;

Сточки зрения структур "С" его надо упаковывать. Но у него все поля выравнены, и с точки зрения программы на ASM никакого выравнивания не надо так как все поля находятся с учетом алигна на своих адресах.

Имеем следующую функцию


Вот на таком примере можете посмотреть на листинг функции с упакованной структорой и нет.

И раскажите в чем выиграш упаковки, в переносимости ? удобстве ? за все это можно заплать ценой более мощного контроллера или кричать что на С код большой и начинать функцию писать на асме, что приведет к полной потере переносимости. Иногда удорожание девайса на 10 центов недопустимо.

Исключением составляют 8 битные процессоры на них код будет одинаковый что с упакованной структурой что нет.


Ну это уже проблемы сугобо личные...

P.S. отредактировал под автора

Собственно примерно так и работал.
В итоге получается что при использовании структур нарушается переносимость кода с платформы на платформу. Например один и тот же код под AVR будет компилироваться без проблем, Под ARM уже могут быть дыры, если элементы структуры не выровнены. Получается для более менее хорошей переносимости необходимо ориентироваться на старший процессор.

Что бы получить кросс платформенность при обмене с внешним миром, без кучи кучи настроек не обойдетесь, так как ядрабывают разные, бывает с разным представление чисел в памяти (LITE ENDIAN & BIG ENDIAN), есть у которых минимальная еденица (char) 16 бит - TMS320VC5502 и т.д. завта появятся 64 битные и т.д.

Вот более переносимый код, я думаю он все же оптималнее чем упакованные структуры, но не факт, прогсто для примера