Re: [boost] [move] Library uploaded to sandbox

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 
news:87fxib8ybh.fsf_at_mcbain.luannocracy.com...> 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