If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: size of structure

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.

Re: size of structure

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).

Re: size of structure

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.

Re: size of structure

Originally Posted by aamir121a

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).

Re: size of structure

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.

Re: size of structure

Originally Posted by 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

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.

Re: size of structure

Originally Posted by laserlight

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)