Re: Serialization (Persistence) library draft submission

From: rameysb (ramey_at_[hidden])
Date: 2002-02-27 16:41:04

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "Yitzhak Sapir" <ysapir_at_y...>
> 
> 
> > > 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 much worse problems with operator>>() than that one, IMO. 
How do
> you unserialize an object with no default constructor?
> 
> -Dave

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.

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

I have a strong affection for using the << operator for this 
purpose.  The basis of this affection is my experience with the 
serialization implementation of MFC.  The relationship between 
streams and archives in this system strongly mirrors that used by MFC 
and I never heard of any problems associated with the usage of << and 
>> operators in this context.

I would be interested to hear more information about what problems 
this could cause.  

Robert Ramey