troy d. straszheim wrote:
The example portable_binary_*archive probably works cross-platform in an *endianness* sense, but not in terms of type sizes. As size_t varies from platform to platform so does the size of, for instance, the "size"s in your vectors in the archive. It took a lot of staring at hexdumps to figure out what nonportable stuff wasn't getting passed up to the portable archive for correct handling.
Another shocker was that bools are 4 bytes on ppc. That took a while to track down.
The implementation I've got looks like this:
void save(bool b) { // catch ppc's 4 byte bools unsigned char byte = b; base_t::save(byte); }
Hmmm - that's not the implementation I've got in the portable_binary_?archive.hpp in the serialzation/examples directory. My implemenation handles all type sizes and endien-ness - (excluding floats/doubles which are not addressed). The only restriction is that the values insertable by the "sending" machine are infact representable by the "receiving machine". For example, one can't send an integer value > 2**32 to a machine which only supports 32 bit integers.
So we need that container_size_type handling in the library. (That's what I was squawking about before, Robert.)
maybe - but not for this.
Specified is that users of the archive either have to use portable typedefs (int16_t) for fundamental types, or they'll have to know for themselves that the fundamentals are the same size when writing/loading cross-platform.
its a good idea for users to "portable typedefs (int16_t)" in anycase in my opinion. The portable_binary_?archives are totally compatible with this. Using these WILL guarentee the the receiving machine will be able to represent the value - if it can be done at all. That is still won't be able to send an int64_t to a machine that doesn't support that type. In this case you'll get a compilation error when you compile the code for the receiving machine - which seems fine by me. Robert Ramey