Portable structure packing

This topic is 3796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hey guys, Just a quick question, is this hack for packing a structure in C++ portable?

#ifdef _MSC_VER

#pragma pack(push)
#pragma pack(1)

#define PACKED

#else

#define PACKED __attribute((packed))__

#endif

struct ThirdPartyStruct
{
...

} PACKED;

#ifdef _MSC_VER

#pragma pack(pop)

#endif


Maybe someone has a better idea? Thanks

Share on other sites
it's not portable. every compiler has it's own "pragma"s.

for gcc use __attribute__ ((packed))

Share on other sites
Okay so it's __attribute__((packed)) and not __attribute((packed))__.

I don't mind if it's not cross-compiler portable, I can make a note and say that it must be compiled using either X or Y, but it needs to be able to be compiled on Windows, Linux and possibly Mac OS.

Since I only develop for Windows, this is new to me.

Share on other sites
I would add an additional #ifdef __GNUC__ around the macro that uses __attribute__, and maybe add a #warning in the #else branch, just to be sure someone trying to build with compiler XYZ will know.

Other than that, it's pretty much as portable as it can be, for the two biggest common compiler suites.

Is it strictly necessary to have the exact same layout/packing, though? Unless that struct is getting dumped straight from memory into a file which should then be read from a different platform (or something similar to this), it shouldn't really matter, as long as your third party code is compiled with the same compiler. ThirdPartyStruct.foo is still ThirdPartyStruct.foo, even with a different layout. Or is that struct coming from a library which you only have in binary form? In that case, forget what I said :-)

Endianness comes to mind too, whenever someone says "portable". You don't plan to exchange structs between programs running on different architectures, do you?

Share on other sites
Since you're packing, and not aligning to certain boundaries, it makes me believe this isn't for SIMD.

What is this for? Hopefully not I/O (files, network)?

Share on other sites
No it's nothing on that scale :P

I'm simply writing some code which reads / writes uncompressed 24-bit BMP files. Unfortunately the bitmap header structures are a mix of integers and shorts, and so it gets padded with extra bytes, which prevents the image from being read by external applications.

Thanks for your help guys, I'm rating you all up.

Share on other sites
Another problem with C++ is member re-ordering : while C mandates the order of members of a structure, C++ implementations are free to move them around to minimize padding.

A portability zealot would advise you to read/write each field separately. extern "C" might be enough though.

1. 1
Rutin
26
2. 2
3. 3
4. 4
5. 5

• 9
• 13
• 19
• 14
• 9
• Forum Statistics

• Total Topics
632940
• Total Posts
3009329
• Who's Online (See full list)

There are no registered users currently online

×