This is something that is really needed in boost. Could you possibly:
a) make a small boost library for this which would include i) code (hopefully header only?) ii) tests iii) documentation
and ask for a mini-review.
b) enhance the portable binary archive to take advantage of your code.
c) enhance the serialization documentation to explain that portable binary archive.
I realize I need to look at the current portable binary archive example code to better understand the design tradeoffs, but there's a number of possible approaches to consider. To me, it makes sense to have multiple portable binary archives, allowing the app to make the best choice for its need (maybe a good "compromise" binary archive could be the default for Boost.Serialization). Possible choices (some already discussed): 1. Absolute smallest space - e.g. "continuation" bits, allowing integers to be 1, 2, 3, 4, etc bytes in size, depending on if the value is (respectively) 127 or less, 32767 or less, etc. (I'm pretty sure this has been discussed before). There could even be a "bitstream" packing versus byte-oriented, but the set of users for that might be pretty small (I've written "bitstream" protocols for wireless networks before, and believe me, the compactness is significantly more than the usual binary network protocols). 2. Absolute fastest speed - XDR fits this, as it is not all that space efficient (e.g. bools take up 4 bytes, short ints take up 4 bytes, etc). But it definitely is 4 byte aligned in everything (however, I would guess that the speed differences regarding alignment are much less for modern processors versus when XDR was first defined). 3. Flexibility versus simplicity - e.g. whether object ids, tags, implicit structuring and nesting, etc are directly supported versus just providing support for fundamental types, and (relatively) simple sequences. 4. Floating point support - IEE 754 formats only versus later standards (and long double), other non-typical floating point formats, and probably a host of other possibilities for binary floating point. 5. Adherence to a commonly used (or even not that commonly used) protocol - XDR, CDR, etc. Cliff