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 , 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk