In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:19:01 -0800 Robert Ramey ([EMAIL PROTECTED]) 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to