Boost logo

Boost :

From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 18:05:50


> > b) implementation of archives in terms of istream/ostream. no
> > registered objections.
>
> I'm actually not really happy with this, but in the absence of
binary
> streams I am unable to offer a better alternative.
>
> > c) binary format archive
> > issues - here is a summary of the binary/text archive issue
> > i) binary data is fundementally non-portable
>
> This is fundamentally untrue. Ones and zeros are as portable as it
> gets, and can be used across all locales and character sets.
>
> > ii) converting to/from text alters floating/double numbers
> > iii) binary storage is considered more efficient
>
> Not to mention less error-prone.
>

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.

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.

That is what I mean when I say that that binary archives are
fundamentally non-portable.

I confess I totally overlooked the question of locale and have yet
to consider it.

I believe it is easier to provide applications with a binary variants
of iarchive and oarchive than to try to come to consensus on one or
the other. I would hope this leaves everyone satisfied.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk