From: rameysb (ramey_at_[hidden])
Date: 2002-02-28 22:29:36
--- In boost_at_y..., "Noah Stein" <noah_at_v...> wrote:
> > 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.
>
> My personal feeling is that serializing back a 64-bit integer on a
different
> platform that does not support a 64-bit integer is really a non-
issue. If
> the data type is not supported, what does it matter that you can't
serialize
> it back? If you think you can work around not being able to get
data out,
> why was it saved in the first place? And if you need a 64-bit
integer on a
> platform that doesn't have one, implement one, then you can
serlialize it
> back.
>
>
> -- Noah
Suppose I write a Computer Aided design package. I have points,
lines in 3D scaling factors and who knows what else. To save
and restore a CAD drawing a use a serialization package. Now
I port the program to another machine. I want to be able to
transfer CAD drawing between machines. In my view if I can't do
that without writing extra code the whole purpose of using such
a library is defeated.
Suppose the two machine have different floating point formats and
precisions. Machine A uses 80 bits of precision while B uses 64
bits. I create a CAD drawing on machine A, serialize (text) to a
file, move the file to machine B, run the ported version of the
program, deserializee the file and start drawing.
What has happened here? Well I lost the 16 least significant bits of
precision so the new drawing is slightly in accurate compared to the
first. But wait who is to say the first program was truely accurate
to 80 bits in the first place. Floating point numbers are always
approximations of some physical measurement or constant. What we
have done is to convert the CAD drawing from the most suitable
representation on machine A to the most suitable representation on
machine B.
So we havn't really transfered the exact object from one machine to
another, which is impossible for this example.
I maintain that this is what we really want to do - How could it be
otherwise? Why would we want to do any other thing.
This is a simple example. What if we use a stream that has been
implemented to read/write to a socket on another machine and we
don't even know what kind of machine it is? How are we going to
address the issue then.
Portability and utility demands the numbers be in some sort of
canonical form. I chose text rendition numbers as that canical form.
Why did I choose this one? Well its the first that came to mind but
there is a real reason. This permits us to leverage on the
float/text conversion functions already programmed for streams in the
standard library. What is the point of writing our own? Are they
going to be better than the ones in the standard library? are they
going to be faster? use much less space? more robust? I doubt it.
I'm willing concede that there may be some special cases where we
want to save/recover a binary stream and I've agreed to add in that
capability. But nothing will convince me that are any thing but
that - special cases.
The concept of storing objects should be independent of
implementation peculiarities. In our CAD example, our interest is
the drawing and the program to manipulated it. The actual bits are
only the means to this end.
At the grave risk of letting this subject go off on to a major
tangent, I'm going to say I hope no one writes and says - I've got to
save all 80 bits of precision on my floating point numbers. A 32 bit
mantissa gives an precision of one part in 4 billion. I doubt any
physical quantities are know with that precision. A 64 bit mantissa
gives a precision of 16 ? (someone help me out here) I KNOW no
physical quantity is known that precisely. If you're concerned about
keeping only 64 or 32 bits of precision, think about what the numbers
truely represent. If you want to respond to this comment maybe you
would like to start another thread.
Robert Ramey