It’s really not a nightmare. All members of a structure will be in the order in which they are declared. You only have to handle type sizes and packing issues.

Use uint32_t, int8_t, etc. to ensure the sizes of types.

Use #pragma pack( X ) to help with packing.

Use static_assert() to make compile-time assertions on the size of the structure and potentially the offsets of each structure member.

This will already give you consistent behavior across most compilers and most platforms. If not, either the static_assert() will trip or you will simply find it and fix it for that platform/compiler once.

I support Visual Studio x86 and x64, Xcode iOS, and Xcode Mac OSX, and have no issues or special cases for any single platform.

The only reason people say it is a nightmare is because they assume you will be using every single compiler ever made for every single platform ever.

This is bollocks. You’ll use 3 compilers ever (+2 more if you get to work on consoles), and in these types of issues they are already compatible. It’s nothing.

L. Spiro

Just one thing that wasn't mentioned yet: in C++, "public:" / "private:" / "protected:" labels define different blocks of variables. Within these blocks, the order is preserved, however the standard doesn't guarantee that block order will be preserved. I've no idea how often reordering is the case in practice, though simply using structs / making all members of a class public will guarantee that there are no ordering issues.

So far Googling has led me to the notion that it's, to quote StackOverflow, "a bit of a nightmare".

The SO ivory tower is a tad different to the real world.
I've seen this type of code, working easily, in almost every game I've worked on and make extensive use of it on my current projects. Just make it a POD struct full of public (default) members, use fixed-size types, and be aware of padding/alignment rules.
Like LS, I use static assertions on the size to catch stupid errors, and static assertions on the offsets if I'm being really careful.
On all the platforms/compilers that you care about, the padding/alignment rules will almost certainly be predictable, fairly sane, and reliable enough to write this kind of code without even having to worry about portability issues.

Biggest portability issue that I have is sometimes I have a pointer field in these structs -- or an integer 'offset' that is converted into a real pointer on load. This creates two different versions of the struct for 32/64bit platforms, which sometimes is fine if you're building the data per platform (just be sure to use a pointer-sized integer), or alternatively I have a typedef for a "cross-platform pointer sized integer", which is basically uint64_t