Re: [boost] Re: Serialization (Persistence) library draft submission

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-03-03 05:22:18

le jeu 28-02-2002 à 10:47, quendezus a écrit :
> 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 :
> 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" );
> 	}

It was said that symmetrical serialisations are a big fraction of the
cases. And here, it's only slightly asymmetrical, currently with Jen's
library I am using a static data member of the descriptors to add a line
specific to loading in such situations :

template<class Descriptor>
void file::describe(Descriptor& desc){ 
    desc & filename;
    if(Descriptor::loading)
        f_ = fopen(fileName.c_str(), "rb");
}

Often in my serialisation needs, there are a lot of straightforward
member data serialisation, and then a few load-time initialisation to
add.
I find this best handled in one single describe function than in
separate load/write..

> 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.

okay, if load code is deeply different from save, it's best coded in a
separate functions.
But a mechanism that calls the single describe unless if  load/write are
overloaded for this type, like in Jen's library, fits both cases.

-- 
Samuel