On Sat, Feb 21, 2009 at 9:24 PM, Rani Sharoni <rani_sharoni@hotmail.com> wrote:
"David Abrahams" <dave@boostpro.com> wrote in message news:87fxib8ybh.fsf@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
Rani, I moderated this post, and should have rejected it because the formatting is unreadable. Please tweak your email program's setting to quote in a readable format, and repost. Thanks, --Beman