Re: [boost] Serialization Draft Submission # 3 - Final Draft

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-27 04:00:26

Robert Ramey wrote:
> Fellow programmers:
>
> I have just uploaded the third release of my proposed serialization
> library.

Hi, Robert!
It's good to know that you continue working on serialization library.
I've tried it yesterday in several ways, and found only one significant 
non-interface problem, but it might require some discussion. Below are my 
observations.

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.

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.

2. archive_exception should really be derived from std::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.

I hope that these issues can be resolved soon. I have some interface 
criticism ready ;-)

- Volodya