On Sun, Nov 17, 2002 at 07:09:00PM +0000, Dave Harris wrote:
> 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.
I think you may be interested to run this program:
#include <iostream>
using namespace std;
struct A {
const int y;
A() { cout << "Construct" << endl; }
A(const A& a) { cout << "Copy" << endl; }
~A() { cout << "Destroy" << endl; }
A(int x) : y(x) { cout << "Explicit construct" << endl; }
};
A foo() {
int somevar = 3;
return A(somevar);
}
int main() {
A boo = foo();
return 0;
}
Observe the *absence* of copies.
Therefore both examples you give above only need to copy the constructor
parameters, never the object. I am using g++ 2.95.4 and 3.2, however I think
this behaviour is also in VC++ and possibly specified in the standard.
> 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 );
> }
*This* might copy three times. (at least two)
So, no better, and probably worse than above.
> > 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.
That is not the case; his solution allows making the serialization method as
a template specialization. It could construct the object however necessary.
> 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.
I think you have a really good point here. :-)
OTOH, there is nothing he can do about this case.
This is the price of data hiding.
---
Wes
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
