Re: [boost] serialization - request for formal review

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