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