Boost logo

Boost :

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

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


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