Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-11-17 14:09:34


In-Reply-To: <01C28E22.C05FEEE0_at_[hidden]>
On Sun, 17 Nov 2002 10:19:01 -0800 Robert Ramey (ramey_at_[hidden]) wrote:
> > const T t(ar);
>
> > It seems to me that your versioning infrastructure doesn't
> > support this.
>
> It doesn't. It conflicted with version and added no known benefit.

The benefit is encapsulated single-step construction without unnecessary
copying. As far I can tell, you have in mind either:

    MyMember member1, member2;
    ar >> member1 >> member2;
    const MyClass mine( member1, member2 );

or perhaps:

    MyMember load_myclass( basic_iarchive &ar ) {
        MyMember member1, member2;
        ar >> member1 >> member2;
        return MyClass( member1, member2 );
    }
    
    const MyClass mine( load_myclass( ar ) );

Both of these involve extra copying. The first involves breaking
encapsulation of MyClass, because the caller needs to know about all of
MyClass's members. The second is more encapsulated (at the cost of yet
more copying of the data) but still has load_myclass() doing the work that
really belongs in the constructor.

Constructors should construct. With the single-step approach, a load
function (if desired) could look like:

    void MyClass::load( basic_iarchive &ar ) {
        MyClass( ar ).swap( *this );
    }

The issues are similar to copy construction and assignment.

I understand the conflict with versioning (although I am not yet convinced
the problems are irresolvable). I don't agree about there being no
benefit.

> Your method would require that every class that uses serialization
> and but no default constructor have code in it that knows about
> archives. Non intrusive serialization could be be implemented in
> this case.

I think you missed out a "not" :-) But no, I am not saying all classes
should work like this. Just that the approach should be supported for
those who want/need to use it.

Incidently, for some classes the MyClass( MyMember, MyMember ) constructor
would have to be added specifically for serialisation anyway. We are
serialising the /internals/ of the class. Those internals won't
necessarily form part of the public interface.

-- Dave Harris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk