size of structure

[aamir121a]

Can anyone tell why the size of this data structure is reported as 16 bytes when it should be 14 bytes ,

typedef struct _Fheader
{
unsigned short a; 2 byes
unsigned int imagesizeb; 4 bytes
unsigned short resc; 2 bytes
unsigned short resd; 4 bytes
unsigned int offset; 2 bytes all = 14 byes

} Fheader;


int _tmain(int argc, _TCHAR* argv[])
{
Fheader fheader;
cout << sizeof(Fheader) << endl ;


Sleep(5000);

return 0;

[D_Drmmr]

Can anyone tell why the size of this data structure is reported as 16 bytes when it should be 14 bytes ,

This is dependent on the compiler and compiler settings you are using. It could be that in your case, a struct is always sized to a multiple of 4 bytes.

[Paul McKenzie]

Can anyone tell why the size of this data structure is reported as 16 bytes when it should be 14 bytes ,

First, this question has been asked so many times, if you did a search, you would find your answer.

Second, there is a FAQ on this:
http://www.codeguru.com/forum/showthread.php?t=276622

Regards,

Paul McKenzie

[ninja9578]

Adding #pragma pack(1) to the top of header files will cause it to be 14 bytes on some compilers, but not all.

Compilers usually compile for optimum speed. You may also get 14 bytes if you use the Os compiling option, but I'm not sure about that.

[egawtry]

What compiler are you using? On most 32-bit machines (including PCs), unsigned int == unsigned long.

If you go back in time to the 80s, then unsigned int == unsigned short.

You can never be sure what the size of an "int" is. Always use char (8 bit), short (16 bit), long (32 bit), and long long (64 bit). There are some compilers that don't properly support long long either.

-Erik

[ninja9578]

Actually, that's incorrect. On most compilers long = long long, not int.

int main(){
    cout << sizeof(char) << endl;
    cout << sizeof(short) << endl;
    cout << sizeof(int) << endl;
    cout << sizeof(long) << endl;
    cout << sizeof(long long) << endl;
    return 0;
}

1
2
4
8
8

[laserlight]

On most 32-bit machines (including PCs), unsigned int == unsigned long.

Actually, that's incorrect. On most compilers long = long long, not int.

Heheh, I think that this just confirms that these things are implementation defined, within the requirements set out by the C and C++ standards. Yet, egawtry did qualify with "most 32-bit machines (including PCs)", so he is not incorrect (other than the assumption that long will be 32-bit instead of 64-bit).

[aamir121a]

thank you guys, however this interesting thing is if i change imagesizeb to short then sizeof structure drops to normal 12 bytes , so while i am changing imagesizeb to short from int the size drops to 12 bytes which i find inconsistent . from int to short the drop is 2 byes and the structure drops 4 byres.

typedef struct _Fheader
{
unsigned short a; 2 byes
unsigned int imagesizeb; 4 bytes
unsigned short resc; 2 bytes
unsigned short resd; 4 bytes
unsigned int offset; 2 bytes all = 14 byes

} Fheader;


int _tmain(int argc, _TCHAR* argv[])
{
Fheader fheader;
cout << sizeof(Fheader) << endl ;


Sleep(5000);

return 0;
Reply With Quote

[aamir121a]

I tried this on windows 7 32 bit and 64 bit gcc mingw and vc 2008 / 2010 compliler resuls are the same

[laserlight]

however this interesting thing is if i change imagesizeb to short then sizeof structure drops to normal 12 bytes , so while i am changing imagesizeb to short from int the size drops to 12 bytes which i find inconsistent . from int to short the drop is 2 byes and the structure drops 4 byres.

Here is one possibility: by default, your compilers are making it such there is alignment along a 4 byte boundary, with reasons due to computer architecture and efficiency. So, a is an unsigned short, and imagesizeb is an unsigned int. Assuming that the unsigned short is 2 bytes in size and the unsigned int is 4 bytes in size, the compiler decided not to place the unsigned int immediately after the unsigned short, since that would place it right smack in the middle of a 4 byte boundary. Therefore, it adds 2 bytes of padding after the unsigned short, leading to a total size of 16 bytes. If you change imagesizeb to be an unsigned short, it would no longer cross over a four byte boundary, thus the compiler does not add padding and the total size is 12 bytes.

As Paul McKenzie noted, you could have read the FAQ and deduced this answer for yourself, or perhaps searched the Web for it (terms such as "structure alignment" and "byte padding" could come in handy).

[aamir121a]

Thank you laser light and Paul McKenzie the answer is that padding is applied to structure , and doing pragma pack(1) will fix it to 14 bytes. thanks to ninja9578. do you know similar compiler flags for GCC / MINGW32 , Further how important is structure alignment when using to read information to structure from binary file header.

[Paul McKenzie]

Thank you laser light and Paul McKenzie the answer is that padding is applied to structure , and doing pragma pack(1) will fix it to 14 bytes. thanks to ninja9578. do you know similar compiler flags for GCC / MINGW32

Most modern C++ compilers have #pragma's that set the structure alignment. Consult your compiler's documentation or search the web for the particular options.

Regards,

Paul McKenzie

[ninja9578]

Heheh, I think that this just confirms that these things are implementation defined, within the requirements set out by the C and C++ standards. Yet, egawtry did qualify with "most 32-bit machines (including PCs)", so he is not incorrect (other than the assumption that long will be 32-bit instead of 64-bit).

Aye, but how many 32-bit machines are there left on the market? My company stopped supporting them all together a while ago.

@aamir121a, most compiled have int16_t, int32_t and int64_t types defined. These are not standard C++, but they do guarantee you that they'll be 16, 32, and 64 bit respectively. (Also uint16_t, uint32_t, and uint64_t)

[Eri523]

Further how important is structure alignment when using to read information to structure from binary file header.

It is extremely important. If alignment handling in your code and in the file is different, they won't match.

[aamir121a]

thank you all , so it is ok to force structure alignment via pragma pack(1) , so the structure perfectly aligns with binary file header , any down side at all.