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