Размер полей структуры

Структура по ходу вообще не нужна

Код (Text):

1. union {
2.   uint32_t pixel;
3.   struct {
4.      uint8_t r;
5.      uint8_t g;
6.      uint8_t b;
7.      uint8_t a;
8.   } colors;
9. } m;
10.  
11. ....
12. m.colors.r = red;
13. m.colors.g = green;
14. m.colors.b = blue;
15.  
16. pixel = &(m.pixel);

 

> Структура по ходу вообще не нужна
что, что? )
а если каждый uint8_r выравнивается по границе в 4 байта?

 

n0name, согласен. Проблема никуда не исчезнет.

 

Простите, а чем а чем не устраивает "упакованная" структура?

Вариант для gcc http://sig9.com/articles/gcc-packed-structures
Вариант для MSVC http://msdn.microsoft.com/en-us/library/2e70t5y1(VS.80).aspx

Собственно, для этого ( вроде как ) и придумывалось.
Кросплатформенности все равно не получите, поскольку выравнивание отдано на откуп разработчикам компиляторов и каждый делает по своему ( хотя и похоже на "соседей" ).

PS: Увлекаться упаковкой не стоит, поскольку для ARM'а, априори будет генериться неоптимальный код. Насколько помню, там все выравнивается по границе в 4-ре байта, следовательно, при работе с отдельными байтами их придется постоянно "распаковавать/запаковывать". Ну и совсем плохо будет, если середина int'а попадет на границу выравнивания.

 

есть такой вариант:

Код (Text):

1. struct color_t
2. {
3.   uint8_t components[4];
4.  
5.   uint8_t& a()
6.   {
7.     return components[0];
8.   }
9.  
10.   uint8_t& r()
11.   {
12.     return components[1];
13.   }
14.  
15.   uint8_t& g()
16.   {
17.     return components[2];
18.   }
19.  
20.   uint8_t& b()
21.   {
22.     return components[3];
23.   }
24. };

 

Считаете, что элементы массива не выравниваются и расположены строго последовательно? Лично у меня по этому вопросу пробел в знаниях... Впрочем, в противном случае не работала бы "арифметика" указателей.
Увы, разместить в массиве можно только элементы одного типа. Хотя, в рамках топика, ИМХО, изящное решение.

 

Там (собственно как и везде) тип выравнивается до кратности адреса размеру этого типа.
Просто на х86 с невыровнянными данными процессор работать может (хоть и с падением производительности), а ARM - нет.

Это гарантируется стандартом.

 

-

 

Кстати, не совсем понятен такой момент. Вот есть спецификация, например, на формат файла:

Код (Text):

1. data offset(octets) size(octets)
2. id 0 2
3. size 2 4
4. name 6 16
5. ...

Этой спецификации я могу сопоставить структуру:

Код (Text):

1. struct file_header_t
2. {
3.   uint8_t id;
4.   uint16_t size;
5.   char_t name[16];
6.   // ...
7. };

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

С другой стороны, каждый раз дёргать вызов read довольно накладно. Наиболее оптимально - смапить файл.

 

Да, хотя по этой спецификации необходимо ставить выравнивание в байт.

 

> Да, хотя по этой спецификации необходимо ставить выравнивание в байт.
это же не кросскомпиляторно!

 

n0name

А что же делать если там стоит конкретный офсет?

 

мапить и читать каждое поле отдельно. В бусте, вроде, есть поток ввода-вывода, завязаный на мапу файла. ИМХО, идеальный вариант. И кроссплатформенность не страдает и с быстродействием проблем не будет.

 

maksim_

Что имеется ввиду под мапить?

 

> Что имеется ввиду под мапить?
наверно 1 раз загрузить файл целиком, а не читать по кусочкам.

 

И как в этом случае обойтись без выравнивания по байту?

 

> И как в этом случае обойтись без выравнивания по байту?
читать по оффсету и без структур.

 

Офигенно удобно.

 

> Офигенно удобно.
ну а что поделать
не писать же разный код для разных компиляторов!

 

имеется ввиду CreateFileMapping MapViewOfFile. В бусте, есть файловый поток mapped_file, предоставляющий аналогичные возможности.