Re: [PATCH] Exploit move semantics in std::accumulate.

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 10 January 2011 18:47, Bo Persson <bop@gmb.dk> wrote:
> Joe Buck wrote:
>
>> On Sat, Jan 08, 2011 at 01:44:21PM -0800, Eelis van der Weegen
>> wrote:
>>>
>>> I briefly talked to a committee member who mentioned something
>>> about Chris already having brought the issue up on the
>>> "non-public-yet-not-secret" mailing list, which would remove the
>>> need for me to do so on the public mailing lists you mention. I
>>> merely asked for confirmation.
>>
>> I hope that the committee will look at the issue not just in the
>> context of this one algorithm, but will make sure that move
>> semantics can be legitimately exploited in all relevant algorithms.
>
> I believe the idea is that as rvalue references are supposed to be a speed
> optimization, the intent of the current draft is to NOT require checks for
> self assignment from an rvalue.
>
> Section 17.6.3.9 [res.on.arguments] specifically says this about library
> functions:
>
> "If a function argument binds to an rvalue reference parameter, the
> implementation may assume that
> this parameter is a unique reference to this argument. ... [ Note: If a
> program casts an lvalue to
> an xvalue while passing that lvalue to a library function (e.g. by calling
> the function with the
> argument move(x)), the program is effectively asking that function to treat
> that lvalue as a temporary.
> The implementation is free to optimize away aliasing checks which might be
> needed if the argument
> was an lvalue. -end note ]"

std::accumulate doesn't take it's init argument by reference, so that
doesn't apply.

The Effects clause explicitly says the accumulation is done by "acc =
acc + *i" which is detectable by users
e.g
struct X { int i; };
X operator+(const X& x, int i) { return { x.i + i }; }
X operator+(X&& x, int i) = delete;