Re: [boost] Serialization Draft Submission # 2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-03-21 03:30:52

Robert Ramey wrote:

> > > 1) Archives are derived from a base class with virtual functions.
> > > This allows applications to implement custom archive formats.  The
> > > library contains support for archives in character text, native
> > > binary data, and wide character text.
> >
> > Great. However, suppose I want to serialize data as xml. Do I have a way
> > to do it? I'm not sure if "basic_iarchive" is a good name. It links in my
> > mind with basic_string/basic_istream &c. where "basic" means something
> > different.
>
> a) I don't see this as really being related to XML.  I did originally but I
> have since changed my mind.  Basically XML contains more information than
> the minimum required here.  XML is interesting to look into but I think
> trying to mix it in here would make things terribly muddled.

I don't mean that basic_{i,o}archive have to deal with XML or any other 
format in any way. They really should do what they do now. 

I thought, however, that there should be some another level, which manages 
translation between the objects into calls to low-level functions that store 
ints and chars. Now I see a problem: in order to make sense of XML, it should 
use reasonable names, and look like
<green_crocodile>
        <age>7</age>
        <weight>200</weight>
</green_crocodile>
However, there's no was to get names "green_crocodile", "age" and "weight" 
without user's help. So it's not possible to get reasonable XML automatically.

I'm now sure now that we need any additional formatting layer. Interesting, 
what others say?

> b) I changed the names of things a couple of times.  Finally I settled on
> the names you find precisely because they mirror the "basic_" used in the
> standard library.
>
> std:string              std:istream                 boost::iarchive
> =======             =========                 ===========
> basic_string         basic_istream              basic_iarchive
> templates on the above for characters
> string                  istream                        iarchive
> templates on the above for wide characters
> wstring               wistream                       wiarchive
> templates on the above for binary output
> -----------	       -------------                        barchive
>
> iarchive >> operators are analogus to istream >> operators
>
> All this is intentional to leverage the namespace already embbedded in my
> aging brain.

Okay, I understand what you mean. 

> > > 2) More checking has been implemented to detect erroneas library usage
> > >
> > > 3) Archives no longer need to store class names.  This makes them
> > > smaller and portable across platforms.
> >
> > I'm missing something and can't easily find it from the code. How the
> > association between classes and class-ids in the stored file is
> > maintained?
>
> well its in the code - though its not obvious .  The key is that all
> objects are written and read back in EXACTLY the same order.  Hence we now
> what class to expect so we don't have to read if from the file.  For
> polymorphic pointers, the procedure is the same though has subtlties that
> can only be understood by reviewing the code.  The basic trick is that we
> "register" the derived class pointers in the same order when we load and
> save so we can identify the class with the object id which is portable.  If
> one is truely interested you can follow the code while displaying the
> charater serialize file.

I'm still at loss. IIRC, derived classes used to be registers using 
"save_register" function (commented out now!), and that function actually 
instantinate a *static* object. The order constructors of this objects are 
executed may well change. Could you explain the mechanics? (and put that 
explanation to the docs)

> > There's one more problem that I've spotted. With virtual base classes
> > your code attempts to save a base twice when serializing the most derived
> > class in a dimond hierarchy. I'll send you an example in a private
> > e-mail.
>
> originally I had code included that suppressed saving of the same object
> twice.  However this failed in cases where the object saved was a temporary
> one on the stack - which often happens with STL objects.  

You mean something like:
        while(....) {
                SomeType s = ....
                oa << s ;
        }
when "s" from different iterations can have the same address?

> I know of no way
> to address this problem in a general way.   Note that saving/loading the
> same object twice causes not problems though it is inefficient.  If the
> this inefficiency is an issue, I believe that the save/load functions will
> have to be made a little fancier to avoid this problem.

There is possible problem if load function for class expects to find it in 
default-initialized state. IIRC, in an old Boland's serialization code this 
problem was addressed by having a separate way to store virtual bases.

> > Some minor nits:
> >
> > 1. Should
> >
> > 	::boost::whatever
> >
> > be replaced with just
> > 	boost:::whatever
> > ?
>
> that's a good question that I don't know the answer to.  I've seen it both
> ways.  Does anybody know what the answer is?

What I think is that inside namespace boost, global qualification is just 
unnecessary: we know that there's no nested namespace boost. Oh...
and actually, inside namespace boost, it's possible to just omit 
qualification.

> I can tell from your comments and your sample code that you have expended
> some effort to try this system out.  Thank you very much - this is very
> helpful.

Thank you for actually doing the work on the serialization library!

- Volodya