Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-01 05:35:11

Robert Ramey wrote:
> I did reply to your message when it was posted. I don't know what
> happened. (Acually I have difficulty replying to messages when the come in
> a batch). Anyway, below you will find your original post along with my
> original response. Sorry for the mix up.

Oh... looking again at your messages I realize that you actually responded,
but without quoting my message. I natually read only the part below my
signature. Sorry.

> > 1. Class registration and numbers.
> >
> > Archives store class numbers, and mapping from class names to numbers is
> > local to archive. Moreover, class names are never written to archive.
> > This cause problems with polymorphic classes.
> >
> > Suppose I write a vector of polymorphic pointers. Each concrete class is
> > assigned a number, but it is required to assure that the numbers will be
> > the same when reading. The only way to archive this in current system is
> >
> > out_ar << static_cast<Derived1* >(0) << ... <<
> > static_cast<Derived15* >(0) .....
> > Derived1* d1;
> > Derived15* d15;
> > in_ar >> d1 >> ... >> d15
> >
> > Here, saving/loading of a dummy pointer creates a consistent numbering.
> > This approach is not optimal
> > - it is not clear who should store/load dummy pointers, (if we don't
> > want to do it manually each time we work with archive.
> > - it might not be possible to do this storing/loading in one place:
> > it is possible that no piece of code knows the full list of derived
> > classes. - it is quite impossible that dummy pointers are written in the
> > same order, especially in different application.
> > (Please see the attached program for illustration of what happens if
> > ordering is not consistent)
> >
> > So, I conclude that this approach is very problematic. I view several
> > layers where serialization might works.
> > 1) For one application
> > 2) Between several applications on one platform
> > 3) Between several applications on different platforms.
> >
> > Current approach has problems with 1). I suggest that when writing class
> > for the first time, it's typeid(...).name() is also written. I believe
> > that MFC and (now forgotten) OWL (from Borland) used this approach. This
> > will make 1) and 2) work. As for 3), I'm not sure we can do anything
> > without portable type_info.
> I believe that you are wrong here. I originally thought that I had to save
> the typeid in the archive. I came to the conclusion that it was not
> necessary. Not specifying it overcame a significant obstacle to archive
> portability.
> The current system works for all known scenarios except circular pointer
> references. This includes all the cases cited above.
> The system is based on the fact that all components are saved and loaded
> in exactly the same sequence. This will always be true unless an error
> has been commited.

I disagree here. Let's consider polymorphic class B and

vector<B*> data;

In order to correctly save this data you'd need to register *all* classes
derived from B. As I say before, there two problems:
1. you have to repeat the registration for each place where you create
archive object.
2. the code which creates archive objects might not know the list of *all*
derived classes.

So, how do you propose to solve this problems, and why the solution can't be
incorporated in the library?

> > Also, as I understand, if a class never seen by the serialization code
> > is written, then type_info_extended::find will return 0 and assert will
> > fail. Prior versions had a way to register a class. I'd like to have
> > that way again in the library.
> writing a NULL pointer of the derived class to the archive is equivalent to
> "registering" the class in the previous system.

Yea, except that this method is not explicit and has the disadvantages I've
explained above.

> > 2. archive_exception should really be derived from std::exception
> I considered this and saw no benefit to doing so. How would this be an
> improvement?

I have exactly the same opinion as Kostya Altukhov: no need to have separate
handler for archive_exception.

> > 3. I'd prefer if documentation describe the format of text archives. The
> > description is already in code, so I guess it would be easy to add it to
> > docs.
> What benefit would this give us. It turns out that the text archives are
> pretty much indecypherable to humans exept for embeded strings. THis is
> due in large part to the filterin out of redundancy.

I withdraw this observation. I think I had it because of attempts of
decyphering the format which is indeed not needed for end users.

- Volodya

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