Re: Serialization (Persistence) library draft submission

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 
(unless
> 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 
is
> that exact representation of a floating/double is going to be non-
> portable.
>
OK. As for fp precision, sticking with a unique compiler will keep 
values
preserved, though.
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
> digits10.
>
> 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 
both
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 
you 
need
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 
locales, 
but
you can use, in the implementation, a secure float<->string 
conversion.
I will put in the files section a couple of generic functions to do 
this.
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 
part 
of an
external object database system (to load/save application documents). 
I
wouldn't be able to do that if the app document were to be written as 
a 
long
text!

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

Regards,

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com