Hello friends,

If we have a struct definition like this

typedef struct s {
char a;
int b;
char c;
} _s;

where because of alignment effects the layout given results in memory
inefficiency, do we need to manually arrange things (char then char
then int) or will a good optimizing compiler automatically reorder the
fields in the struct?

Also if we do arrange it as char then char then int, the first dword
in the struct will have two char bytes and two padding bytes. How will
the compiler organize the space and why? Will it be
padding - padding - char - char
or padding - char - padding - char
or char - char - padding - padding
etc.?

Thanks.

pradeep wrote:
> Hello friends,
>
> If we have a struct definition like this
>
> typedef struct s {
> char a;
> int b;
> char c;
> } _s;
>
> where because of alignment effects the layout given results in memory
> inefficiency, do we need to manually arrange things (char then char
> then int) or will a good optimizing compiler automatically reorder the
> fields in the struct?
>
No, the order is fixed.

> Also if we do arrange it as char then char then int, the first dword
> in the struct will have two char bytes and two padding bytes. How will
> the compiler organize the space and why? Will it be

That is entirely up to the compiler.

--
Ian Collins.

pradeep <nospam@nospam.com> writes:

> If we have a struct definition like this
>
> typedef struct s {
> char a;
> int b;
> char c;
> } _s;
>
> where because of alignment effects the layout given results in memory
> inefficiency, do we need to manually arrange things (char then char
> then int) or will a good optimizing compiler automatically reorder the
> fields in the struct?

The compiler can't re-order the struct.

> Also if we do arrange it as char then char then int, the first dword
> in the struct will have two char bytes and two padding bytes. How will
> the compiler organize the space and why? Will it be
> padding - padding - char - char
> or padding - char - padding - char
> or char - char - padding - padding

The only options are ones that have no padding at the start. That
leaves three possibilities. I'd lay odds on it using char, char,
padding, but you can't assume that it will do so.

As to why, the usually strategy is that the compiler puts a field at
the first offset that will incur no access penalty.

--
Ben.

>If we have a struct definition like this
>
>typedef struct s {
> char a;
> int b;
> char c;
>} _s;
>
>where because of alignment effects the layout given results in memory
>inefficiency, do we need to manually arrange things (char then char
>then int)

It is not necessary to optimize for memory (or for that matter, any
kind of) efficiency until you've proved it's unacceptably bloated.
Most people seem to be worried about SPEED more. If you're worried
about the memory efficiency of this struct, presumably you are
allocating at a minimum tens of thousands of them.

>or will a good optimizing compiler automatically reorder the
>fields in the struct?

No, a C compiler is not allowed to reorder the fields in a struct.

>Also if we do arrange it as char then char then int, the first dword
>in the struct will have two char bytes and two padding bytes. How will
>the compiler organize the space and why? Will it be
>padding - padding - char - char
>or padding - char - padding - char
>or char - char - padding - padding
>etc.?

The compiler can add padding after any field (but not before the
first field). It is not allowed to re-order fields.