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

From: Damien Fisher (damien_at_[hidden])
Date: 2002-02-28 20:18:13

On Thu, 28 Feb 2002, Rainer Deyke wrote:

> ----- 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:

It strikes me that this is a problem with serialization to text-based
files anyway.  I mean, if you serialize a 64-bit integer to a file and
then deserialize it on a 32-bit platform with no "long long" or "__int64",
what are you going to do?  So the issue is the same regardless of whether
we are talking about text or binary, IMHO.

Personally, I think any serialization library that does not support binary
is next to useless for many tasks (due to the increased size of the file).

An analogy: text is to binary like XML is to text. :)

Damien