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

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

> 1) the class iarchive and oarchive are not derivations of streams.  
> They are implemented in terms of strings.  the << operator for all 
> primitives are implemented to add a space after a number.  Other 
> stream operations are not implemented by archives. so iarchive << 23 
> << 34 results in "23 34" being appended to the archive.  There is are 
> special << and >> for strings.

I saw that you deal with the fielded output issue (putting a space after
each field) after I wrote the message.  None of the other points I
brought up are dealt with, though.  Particularly, you implement the
archive in terms of a stream object.  This in itself is not bad, except
you use << and >> on that stream to serialize numbers.  Consider now
that two people are working with different locales.  A locale can have a
numpunct facet.  Consider one locale defines a numpunct that specifies
that decimal point is a comma, thousands separator as a period, a
grouping of 3, 3, -1, truename of "aye", falsename of "negative," and
has already put in boolalpha in your stream properties.  You couldn't
read it on a different locale.  The problem is that you are using the
streamed formatted output routines.  Besides the fact that your writing
and reading will not work this way on machines with different locales,
there is the more simpler fact that, in my opinion, for serialization
purposes, one shouldn't use formatted output which is much more
time-consuming, much more bandwidth/space-consuming and simply
unnecessary.

Formatted output and serialization are two different things.  It's nice
that MFC did it this way.  And I also, in my serialization system did it
this way (using num_get and num_put overloading), but I now regret it
and consider whether the costs of changing it (a lot of changes) really
outweigh the benefits of doing it (a more simpler to manage system and
the ability to specify different types of serialization via additional
parameters).  It may be a common thing to do, because the >> and << are
really easily confusable with serialization.  But they aren't.  A
requirement of serialization, in my opinion, is the ability to convert a
serialization to formatted output.  However, just because it should be
convertible to formatted output doesn't mean that serialization is or
should use internally formatted output.  If STLPort can write stream
text i/o for a wide variety of machines, you can write stream binary
serialization i/o for a wide variety of machines.  It may be a little
work, and a little hassle, to deal with various machine representations
of numbers, floating point, and big/little-endian, but it's also what
people might expect in such a library.

I'm also wondering whether it's reasonable to expect automatic
serialization primitives for any POD datatypes (similar to how type
traits and copy can be used to optimize to memcpy).  I also have in my
serialization system a method that allows me to specify a typelist, and
then to have a type of that typelist being sent out and back on the
stream, and compile time checks against almost all common errors I
wanted to catch, (such as not specifying particular operations on a
type), and hopefully soon, log n runtime searching in the typelist upon
deserialization of a particular type.  I'd like to have that too (that's
why I wrote it).

> 2) it is a requirement that any object de-serialized through a 
> pointer have a default constructor.

Doesn't that reduce the genericity of the system?  I don't need to have
a non-default constructor in my system.  But maybe someone should be
able to specify a policy that says "I do want to first unserialize some
types, and use them in a call to a non-default constructor."  You also
claimed that "Absolute minimal coding required to add serialization."
David Abrahams pointed out that for simple types one should be able to
describe the type once so that the reading/writing routines don't have
to basically contain the almost-same code twice.  Your code doesn't
allow for this, so maybe it's not "absolute minimal coding required" as
a result.  (This might be simple to add, though, to your current
framework, be it good or bad.)