Subject: Re: [boost] [move] Library uploaded to sandbox
From: Rani Sharoni (rani_sharoni_at_[hidden])
Date: 2009-02-22 12:58:04


"David Abrahams" <dave_at_[hidden]> wrote in message
news:m23ae6e634.fsf_at_boostpro.com...
>
> 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 :-)

I was just commenting about your explenation and not your understanding
about the application.

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

I don't know much about the Adobe approach but AFAICT, given a viable copy
ctor, both should work even when the frontend optimization doesn't take
place.

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

I was commeting about the move-enabling members in general and such are
needed if move from lvalue is required.
OTOH, the move-enabling members can be implemented in other ways since they
are actually not related at all to the rvalue case.

Rani