Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at