I have a struct with 2 members of type double and 1 member of type long.
The sizeof() function returns 24. Normaly it should be 20(2*8bytes for the doubles and 4 bytes for the long).
When I add a another member of type long sizeof() returns 32.
Another struct with 3 longs returns 12 with sizeof().
I suppose it has something to do with allignment and optimalisation? How can I avoid this.
Luc Vercruysse
your struct was probably patched by the compiler to make it more comfortable to work with. also note that on an ARM is it generally more efficient to leave the smallest structure elements for the end of the structure.
A struct always gets its size adjusted to be n times the member with the highest alignment requirement.
If you have an 8-byte double in the struct, then the struct must be n*8 bytes large, so your first example will need four bytes of padding.
If you place the two long values directly after each other, then the modified struct should stay at 24 bytes. If you have one or more double between the two long, then the compiler needs two padding areas of four bytes each, resulting in a total size of 32 byte.
"on an ARM is it generally more efficient to leave the smallest structure elements for the end of the structure"
The general case for any processor that can take advantage of alignment is that you get the smallest and most efficient structures if the data is grouped on increasing or decreasing align requirements.
one long and one short and two byte can be grouped into 8 bytes if the align sizes are sorted in increasing or decreasing order. Any other combination will result in extra padding.
If you really need to get rid of the 'holes' in your structure, then you should consider 'packing' them.
Refer to:
www.keil.com/.../armccref_cjafjhjd.htm
Note that doing this can have a negative effect on code speed and size.
yes, because the compiler *must* assume each assess to the structure might be unaligned, which means extra shifts.
Thanks for very fast reply !!!
Normaly it should be 20
Just to make this crystal clear: this statement expresses a fundamentally incorrect belief. The size of a struct is nothing for you to decide about what it "should" be. It is what it is, period.
Struct and alignment and member padding is the compiler's job. You'll fare better not trying to second-guess it.
It is true that the size of structures shouldn't be second-guessed. But it is very valuable to know why the compiler does what it does. With some knowledge, you can produce smaller structures.
In embedded products, a better optimized size can be the difference between fitting all variables in the existing RAM or not. For PC-class processors, an optimal order of the individual fields can make the struct fit in one instead of two cache lines, or can make one extra struct fit in the same cache line. The speed difference can be very significant.
But in the end, it's the sizeof operator that is king. Any code that assumes struct sizes instead of using the sizeof operator are highly nonportable.