Boost logo

Boost :

Subject: Re: [boost] [move] Library uploaded to sandbox
From: Rani Sharoni (rani_sharoni_at_[hidden])
Date: 2009-02-21 21:24:15

"David Abrahams" <dave_at_[hidden]> wrote in message> Wow, this is way cool: you've
found a way to allow the default> copy ctor and assignment operators to be
in place, and yet still treat> rvalues specially! I guess that's because
overloading prefers derived> classes: No. this is because of return value
optimization in which the temporary is constructed directly into destination
and therefore the copy ctor is not called (hence its definition is not
instantiated in your case). This is common frontend optimization but it
might be fragile assumption. Try removing the "move-enabling" members or put
the copy ctor as private to see. The "move-enabling" members are only
effective for the explicit move (via move(lvalue)) so they are essential
after all. > template <class B>> struct D : B> {};>> template <class T>>
struct B {> operator D<B>&() { return *static_cast<D<B>* >(this); }>>
B() {}>> B(B const&) // move ctor> { T::copy_ctor_called(); }>>
B(D<B>& x) // move ctor> { }>> };>> B<int> f() { return B<int>(); }
// <== most likely elided; otherwise > move> B<int> x(f());
// <== calls move ctor> B<int> y(x); // <== calls copy
ctor, generating error Rani

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