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
> > 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
> 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
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
2. the code which creates archive objects might not know the list of *all*
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
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk