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

Subject: Re: [boost] [move] Library uploaded to sandbox
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-22 12:26:07

on Sat Feb 21 2009, "Rani Sharoni" <rani_sharoni-AT-hotmail.com> 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. 

Since it turns out I am the inventor of this technique, I'd like to see
why you think I don't understand it :-)

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

Argjjh, you're right.  So in this respect it's almost identical to the
Adobe approach.  Are there any substantial differences?

> The "move-enabling" members are only effective for the explicit move
> (via move(lvalue)) so they are essential after all.

I wasn't trying to say the move-enabling members were inessential... but
even if I was saying that, I'm afraid I don't understand what you mean.

Rani 

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com