From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 18:30:59
----- Original Message -----
From: "bonyicecream" <bonyicecream_at_[hidden]>
To: "Fernando Cacciola" <fcacciola_at_[hidden]>
Sent: Thursday, February 28, 2002 1:49 AM
Subject: Re: Serialization (Persistence) library draft submission
> --- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> > Actually, there is not such a thing as a C++ implementation
> you are
> > referring to a compiler, but that's not the case).
> > There are library implementations.
> I mean to say that different C++ compilers have different floating
> point precision. my watcom compiler lets you choose. So my point
> that exact representation of a floating/double is going to be non-
OK. As for fp precision, sticking with a unique compiler will keep
But even with a single fixed compiler, conversion from and to text via
iostreams is not required to preserve values.
> > BTW, in your code you've used numeric_limits<>::digits, instead of
> Thank you. I'll fix that
> > IMO, since the purpose of writing an fp value is to retrieve
> exactly later,
> I believe the only way to really address this is with binary archive
> format. So the choice is either archive portability or exact
> restoration of floats/doubles.
Actually, a binary archive would guarantee exact restoration only if
output/input are run in the same platform.
You already realized this and decided to use a text representation.
Using a text representation is a good idea. The main issue is that
a value-preserving float/string conversion.
This doesn't happen with your current code because it uses the stream
specified by the user, which might have peculiar and differing
you can use, in the implementation, a secure float<->string
I will put in the files section a couple of generic functions to do
You can use that in your code if you like (once I had uploaded it).
> I already Have one vote for the option to use binary format - at the
> cost of portability of archives. (Mathias). I'll put you down for
> vote number two.
Yes, I like binary archives because of size/speed matters.
For instance, I might decide to use your serialization library as
external object database system (to load/save application documents).
wouldn't be able to do that if the app document were to be written as
> I have concluded that including an option for binary format is not
> very hard and that if I get 5 votes for it then it will be easier to
> to implement rather than dispute it.
I think that it can also be added afterwards, as an addition.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk