Re: [boost] [multiprecision] Some rvalue reference experiments (performance inhancements #1)

Subject: Re: [boost] [multiprecision] Some rvalue reference experiments (performance inhancements #1)
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-08-04 16:47:19

[Finally going through my back-log of MP discussion emails...]

On Sat, Jun 30, 2012 at 10:17 AM, Marc Glisse <marc.glisse_at_[hidden]> wrote:

> On Sat, 30 Jun 2012, John Maddock wrote:
>
>  I've started to work through some of the points that came up in the
>> multiprecision review, starting with further rvalue reference support.
>>
>> The idea (due to Marc Glisse) was to add operator overloads that look
>> something like:
>>
>> Number&& operator+(Number&&a, const Number& b)
>> {
>>  return static_cast<Number&&>(a += b);
>> }
>>
>
> The safe solution is returning Number, not Number&&. If Dave reads this
> message, he can probably point us to previous discussions about this. Being
> able to return Number&& would be great...
>

The problem is illustrated via something like

a = move(a) + b;

Of course, the above is better written as "a += b", but it's exemplary of
more elaborate assignments, e.g., "a = c * move(a) + b". Indeed, an even
simpler example is just "a = move(a)", given John's implementation of
operator+ above and ignoring the arithmetic (which is not relevant). And
the problem with "a = move(a)" in a generic context is that
T::operator=(T&& x) may freely assume that this != &x [1], mostly for
efficiency purposes (Dave, correct me if I'm wrong here).

So, in other words, don't return an rvalue reference from a function which
is a reference to one of its arguments unless this is explicitly intended
and documented (e.g., move and forward).

Note that changing the return type from Number&& to Number cancels the
> allocation gain when using a type like GMP that doesn't have an empty state.
>

Huh, really? That's no good.

- Jeff

 [1] http://cpp-next.com/archive/2009/09/your-next-assignment/