Re: [boost] Re: Serialization (Persistence) library draft submission

From: Rainer Deyke (root_at_[hidden])
Date: 2002-02-28 19:11:35

----- Original Message -----
From: "rameysb" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, February 28, 2002 4:05 PM
Subject: [boost] Re: Serialization (Persistence) library draft
submission

> The issue that has concerned me is what happens when an archive
> is created on a machine with 80 bit IEEE floating point doubles and
> this archive is read by a program using the same serialization
> library on a machine which has 64 bit doubles.  if the second
program
> reads 80 bits is it going to have to include code to convert from
> every known binary double format to every other one?  The same
> issues occur on sizes of other binaries 16 vs 32 vs 64.  The same
> issue arises when considering that some machines store integers
> in little endien order (intel) while others store them
> in big endien order (sparc).  I doubt anyone will want to
> consider all these issues.

It is only necessary to support one standard format with conversions
to/from native.  In my personal serialization code I use 32 bit
integers (and 32 bit long, 16 bit short, 8 bit char), big endian, 2s
complement, and no floating point.  My reasoning is as follows:

  - Most of the platforms I use have 32 bit integers, so I chose to
support that.  On platforms with more bits per integer, the high bits
are dropped during serialization.  This is not necessarily a bad
thing, since integers with >32 bits cannot be portably read on 32 bit
platforms.  On platforms with less than 32 bits per integer, the high
bits are dropped during deserialization, which is bad but unavoidable.

  - I chose big endian because it is more standard and because it
demonstrates that I do not rely on native endianess.

  - I do not explicitly enforce a standard system for negative
numbers.  Instead I just cast the variable to an unsigned type and
serialize that.  I do not anticipate porting my programs to a platform
with a different representation of negative numbers.

  - I currently do not use floating point variables.

  - I also assume that 'char' is an 8 bit byte.  I do not anticipate
porting my programs to a platform where this is not the case.

Overall, my design decisions may not be suitable for inclusion in a
future Standard, but they do demonstrate that these issues can be
solved.

> if you port your program to another environment, and you use binary
> format you cannot be sure that any archives created in the original
> environment can be read.  If the archives are as formated text this
> problem will not occur.

If you use text, you run into trouble over different character
sets/newline conventions/locales.  I believe that a standard binary
format is safer.

--
Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com