[boost] Re: Re: Re: [serialization] default-constructors

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-06 04:30:51

Dave Harris wrote:

> In-Reply-To: <blqvc0$mhl$1_at_[hidden]>
> ghost_at_[hidden] (Vladimir Prus) wrote (abridged):
>> As Robert noted, you still have to make load_construct a friend of the
>> serialized class.
> 
> No, you can instead overload it for the serialised class. You can add the
> overload without modifying the class. It is a non-intrusive approach.
> 
> I seem to say this in every message, yet people don't seem to get it. I
> don't know how to say it any clearer. I know you saw the example, because
> you comment on it below.

Personally, I don't care much about non-intrusiveness at the moment. The
price for including <boost/serialization/access.hpp> is rather low and
adding 'load_constant' overload is a bit too complex for me. And again, if 
I don't have public default ctor, then I'll have to make 'load_constant' a
friend.

>> Eh... you gave the following example:
>> 
>>  template<class Archive>
>>    void load_construct(Archive & ar, my_class *pt, unsigned int version)
>>    {
>>        int a;
>>        ar >> a;
>>        new( pt ) my_class( a );
>>        load( ar, *pt, version );
>>    }
>> 
>> It's good, but it presumes that "save" method has written "a" for you to
>> load. That's somewhat breaks duality between "save" and "load". Now
>> "save" should care about another function "load_construct", which is
>> somewhat more complex.
> 
> In the current proposal, the pointer version of load:
> 
>     template<class Archive ar, class T>
>     void load(Archive & ar,  T * &t,  unsigned int file_version);
> 
> is paired with a pointer version of save:
> 
>     template<class Archive ar, class T>
>     void save(Archive & ar, const T * t, unsigned int file_version);
> 
> In the same way, in my suggestion load_construct needs to be paired with a
> save_construct (there may be a better name). The library uses
> save_construct to save in those situations where it knows it will be using
> load_construct to load. A user who overrides ones must also override the
> other.
> 
> Sorry I didn't mention this before - I thought it was obvious. Every load
> function needs a corresponding symmetric save function. Duality is
> preserved. Do you see any reason this can't be done?

This certainly can be done. The problem is that save/load is simple: you
store some members in one and restore that in another. Saving some members
in one function and other members in another can be confusing. Need to
decide which one to overload might be confusing.

To tell the truth, I don't know enough about use cases where one would want
to write complex "save"/"load" functions... maybe we need more experience.

>> FWIW, in my use case it won't work, since I don't have any ctor which
>> can be used to reconstruct the class instance given field values.
> 
> If there is no constructor, how do you make instances? You understand that
> your custom load_construct can follow construction with a normal
> serialisation load?

I have two ctors: one which takes lots of arguments, some of which cannot be
serialized and are actually used only in ctor, and a private default ctor.
I can make 'load_construct' use the latter and follow by 'load', but then I
only get more typing, compared to the case where serialization lib accesses
the default ctor itself.

- Volodya