|
Boost : |
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;
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk