From: Robert Ramey (ramey_at_[hidden])
Date: 2005-11-18 11:01:24
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;
Hmmm - that's not the implementation I've got in the
in the serialzation/examples directory. My implemenation handles all type
sizes and endien-ness - (excluding floats/doubles which are not addressed).
only restriction is that the values insertable by the "sending" machine are
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,
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.