RE: [boost] Re: Serialization (Persistence) library draft submission

From: Yitzhak Sapir (ysapir_at_[hidden])
Date: 2002-02-27 13:32:11

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