From: Rainer Deyke (root_at_[hidden])
Date: 2002-02-28 19:11:35
----- Original Message -----
From: "rameysb" <ramey_at_[hidden]>
Sent: Thursday, February 28, 2002 4:05 PM
Subject: [boost] Re: Serialization (Persistence) library draft
> 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
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk