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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-06 08:28:26

Dave Harris wrote:

> In-Reply-To: <blrcok$dkr$1_at_[hidden]>
> ghost_at_[hidden] (Vladimir Prus) wrote (abridged):
>> Personally, I don't care much about non-intrusiveness at the moment.
> 
> Well, fine. This stuff may be solving a problem you don't have.

Exactly.

> Non-intrusiveness is important for other people, because it can enable
> serialisation of 3rd party classes for which the source can't be changed.
> Supporting it is one of the design objectives.

I know about it.

>> 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.
> 
>>From what you say later, I think you mean you don't have any public ctor
> that serialisation can use, whether default or not. In that case you can
> continue doing what you are doing. Don't overload the default
> implementation, but do add friend so it can use your private constructor.
> My suggestion is irrelevant to you; it neither adds nor subtracts.

Actually, it adds work for me. I need one additional friend declaration.

>> 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.
> 
> That issue is present even without my suggestion. The difference is that
> in the current library, the four functions to overload are:
> 
>     template<class Archive, class T>
>     void save(Archive & ar, const T & t, unsigned int version)
> 
>     template<class Archive, class T>
>     void load(Archive & ar, T & t, unsigned int version)
> 
>     template<class Archive ar, class T>
>     void save(Archive & ar, const T * t, unsigned int file_version);
> 
>     template<class Archive ar, class T>
>     void load(Archive & ar,  T * &t,  unsigned int file_version);
> 
> where-as with my suggestion the last pair are replaced with load_construct
> and save_construct. Either way, the last pair are to deal with relatively
> esoteric cases which most people can ignore.
> 
> I'm just saying that if we reformulate the last pair slightly differently,
> we can handle a few more of the esoteric cases. In particular we can
> provide serialisation for std::vector without requiring a default
> constructor, and without users having to write it by hand.

I might be missing something, but looks you're splitting the last "load" in
"load" and "load_construct". You've shown how to use "load_construct" part,
but is there any need to use "load", after it's split from
"load_construct". If no, then maybe it's not good to call it "load"? 

Maybe, what you're after is moving the "try"/"catch" from pointer "load"
into serialization lib, and making pointer "load" accept uninitialized
pointer?

> If anything, I think my suggestion is less confusing. This is partly
> because the current scheme reuses the name "load" to mean different
> things. The signature suggests that I need to overload the pointer version
> if I want to load pointers. In fact, I only need to do that if I want to
> take control of object creation. In practice pointers can be loaded
> without using the pointer version of load, eg because the object already
> exists. Perhaps, if we decide to stick with the current scheme, we should
> at least rename the second pair to "load_create" or similar, to reflect
> their real purpose.

I don't have an opinion here.

- Volodya