Re: Serialization (Persistence) library draft submission

From: rameysb (ramey_at_[hidden])
Date: 2002-02-27 16:48:51

--- In boost_at_y..., "Yitzhak Sapir" <ysapir_at_y...> wrote:
> > 3) ar << * static_cast<const bus_stop *>(this);
> > 
> 
> Implementing serialization with << and >> is nice, and it allows 
you to
> write code like this:
> 
> 	socketstream << some_object;
> 	cout << some_object;
> 
> which looks very generic.  In fact, you may not even need to know 
which
> type of stream you're serializing too.  However, This is also
> problematic.  << and >> were not meant for serialization of 
restorable
> non-fielded data as far as I can see.  That is, cout << 23 << 34;  
would
> print 2334.  Sent to a file and read back to an int, you'd 
read "2334".
> There are two possibilities I know of:
> 
> 1) Require your users to be aware of this:  All users do cout << 23 
<< '
> ' << 34 << ' '; after every int serialized.  This is problematic as 
it
> requires your users to be aware that they have to print fields 
between
> the data.  Besides, for serializing non formatted data, it is quite
> space-consuming.  (A 4 byte number can take 10 ascii digits, or 20
> unicode chars).
> 
> 2) Reimplement num_get and num_put and place them in the locale of 
the
> serialized stream.  This is problematic as num_get and num_put do 
not
> have complementary functions.  Particularly, num_put can only 
serialize
> types bool, long, and unsigned long as far as integers are 
concerned.
> num_get can read shorts, etc.  Consider now that a user writes a 
short
> to the stream, then the long put function will be written, and a 
short
> will be consequently read.  So num_get's short methods would have 
to be
> reimplemented to also know that they read a long.
> 
> Both of these are compounded by the fact that formatted 
serialization
> takes place with << and >>, which is much slower (as it must 
implement a
> more robust system) than would need to be for the purpose of
> non-formatted serialization.
> 
> This only happens if you use a basic_*stream derivative, but it 
seems
> (from a brief look at the code) that you are.  I should also note 
that
> you may want to make the archive templated by Char and CharTraits, 
and
> follow the basic_*archive/*archive/w*archive framework.  So this 
way if
> you're serializing to a wchar_t stream that has a unicode code
> conversion you don't have to lose information on serializing a 
wstring,
> or have to follow additional steps to prevent this.

input and output archives are not derived from streams.  They are 
implement in terms of strings.  This is addressed in the "Rational" 
section of the documentation.  The reference to the stream to be used 
is passed when the archive is created.  So all issues associated with 
streams are orthogonal to archives.

also the rational for using text for numbers - is portability from 
machine to machine.  binary portability would be a huge hassle and 
never be complete.  Its bad enough that there are little and big 
endien machines, floating point formats vary from machine to 
machine.  I believe that the only practical way to make archives 
portable across machines to use text files.

Robert Ramey