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

Subject: Re: [boost] [move] Library uploaded to sandbox
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-02-22 08:14:57

On Sat, Feb 21, 2009 at 9:24 PM, Rani Sharoni <rani_sharoni_at_[hidden]> wrote:
> "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

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