Boost logo

Boost :

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
>> 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


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.



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