and pragma pack(1) works with MINGW as well to will try this for GCC under linux
Printable View
and pragma pack(1) works with MINGW as well to will try this for GCC under linux
Of course, there is a downside. Otherwise, why do you think the default option would be to waste memory?
If you need to read a struct from a binary input, then read the elements one by one. Packing may give you a small performance gain on reading/writing (which is slow anyway), but cost performance on other operations (which are typically not slow).
Also, you should carefully consider whether the binary representation of a type will always be the same. The posts above show that this is not the case for different compilers / platforms. Unless you can exclude such cases, I wouldn't advice using binary files.
Be careful with pack(1) or __align; A lot of processors do not allow mis-aligned ints. ARM, Blackfin, SHARC, and several others will crash if you don't have the BYTE, WORD, or DWORD on a 16 bit boundary.
By the way, all MS Windows compilers:
char = _int8_t = 8 bit
short = _int16_t = 16 bit
long = _int32_t = 32 bit
long long = _int64_t = 64 bit
----------------
-Erik
I'm confused why you're writing your own bitmap loader anyway. There are tons of them out there for both loading standard bitmaps and windows bitmaps. They will do memory alignment, row padding, header loading and validating all for you. Bitmaps are weird. For instance, if the header says that the bitmap is 3 bytes per pixel, and it's 10 pixels wide, how many bytes is one row of the bitmap in the file? I'll give you a hint, it's not 30.
FYI, the only guarantee is:
As stated in the C++ specs. For some compilers, these are all '1'.Code:sizeof (char) = 1
sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)
Viggy
The only guarantees with respect to size in bytes, yes. However, it is not the only guarantee when we include range. For a standard conforming implementation on which sizeof(char) == sizeof(long), it implies that the range of char would be at least [-2147483647, 2147483647] if it were signed, or [0, 4294967295] if it were unsigned. I find that rather unlikely, though certainly possible.