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

From: Dave Harris (brangdon_at_[hidden])
Date: 2003-10-06 06:51:58

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

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

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

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.

-- Dave Harris, Nottingham, UK