Boost logo

Boost :

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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at