$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: quendezus (quendez_at_[hidden])
Date: 2002-02-28 04:47:54
--- In boost_at_y..., Vladimir Prus <ghost_at_c...> wrote:
> 
> I have the following comments:
> 
> 1. It would be much better to stick to the scheme with one function 
> 'desciribe'. This would allow to reduce code size needed to make an 
object 
> serializable, and will also allow using the same 'describe' 
function with 
> other classes. Is there any problems that I've missed? (but see 
point 4 below)
> 
> ...
> 
> 4. Versioning is completely omitted from documentation. How does it 
work? Can 
> I disable it completely? Oh... and now I sense some problem 
with 'describe' 
> method -- it will have to describe specified version of a file. And 
what to 
> do with member variables with were added in the last 
version? 'load' version 
> can contain arbitray logic to set their values. 'describe' will 
have no way 
> to do it, so we'll have to either rely on defaul-initialization to 
be ok, or 
> provide and additional function which does 'fixup' after a old 
version of 
> class was loaded.
> 
> - Volodya
>
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_m...>
> 
> If you're willing to require a default constructor, shouldn't you 
also find
> a way to describe the type once so you don't have to code a reader 
and a
> writer that look nearly identical?
> 
> -Dave
>
I don't think the 'describe' scheme is good. Volodya noticed a 
problem with member variables added in a late version, but the 
problem is more general. See the example below :
struct file
        {
        std::string fileName_;
        FILE* f_;
        file( const std::string& fileName ) : fileName_( fileName )
                {
                f_ = fopen( fileName.c_str(), "rb" );
                }
        };
void save( archive& a, const file& f )
        {
        a << f.fileName_;
        }
void load( archive& a, const file& f )
        {
        a >> f.fileName_;
        f.f_ = fopen( f.fileName_.c_str(), "rb" );
        }
I consider the load function as a constructor that takes its 
parameters from the archive (that is why it seems odd to me to 
imagine a deserialization on an object not built with its default 
constructor). In the load function you sometimes need some code (fopen
( ) in my example), exactly like in a constructor.
Moreover, the 'describe' scheme implies a symetrical management of 
the serialization/deserialization, that I have rarely seen in real 
life code. On the load side you can have validation code, debug code, 
etc. In the save side you can have parsing of the serialized data to 
see which one to keep given the state of the program, etc.
Sylvain