Boost logo

Boost :

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

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


Dave Abrahams
BoostPro Computing

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