Re: [Boost-users] boost::serialisation -portable_binary_oarchivenotpart of library

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-27 12:04:01

Oliver.Kowalke_at_[hidden] wrote:
> Hello Robert,

> Serialisation for std::strings and chars are supported in a portable
> manner?

This starts to raise the issue of what it means for a binary archive to be
portable.  Suppose an archive is created on an ascii machine and
read on an ebcdic machine.  Or more commonly, an archive is
created in an environment is such that the default multi-character
encode is latin characters and read my a machine whose
multi-character encoding is Japanese characters.  Should characters
be translated.  The native binary archive assumes no portabilty
requirement and that the only requirement is maximum speed.  A
portable binary archive has to start making lots of decisions and
trade offs.  What is fast/universal format for floats/doubles/etc,
how to handle things like invalid floats, nans, +/- inf, +/- 0, etc.
What about endienness? the portable binary archive include
creates a specific endienness.  This will be a performance issue
for machines that don't match the endiennes chosen.  So someone
will say they want o choose the endieness with some sort of
switch or perhaps create the archive with the native endieness
of the creating archive and make an adjustment on the fly
if the recieving machine doesn't match.

Oh and some have suggested that a common format such
as XDR be used.

As it typical, something starts out seeming simple, but by
the time you get to the point of trying to "sell" it to the
boost community it morphs into something pretty much
impossible to implement and still get a concensus for
acceptance.

So, I've left these issues for someone who has a need for
such a thing.  As I said, it seems no one has had such a need
to actually do any work - so there it stands.

Good Luck

Robert Ramey

> Only floating point types have to be implemented for portability?
>
> Oliver
>
>> I made it as an example on how to extend the library by deriving
>> from an existing
>> archive.  To "finish" it would require implementing serialization of
>> floating point
>> types in a portable manner and this turns out to be a non-trivial
>> task. Implementing
>> this would be too much work and would sort of compromise
>> illustrative value of the example.