Re: [boost] [operators] A modern SFINAE-based version of boost::operators?

On 11/14/2017 1:16 PM, Daniel Frey via Boost wrote:

...

On 14. Nov 2017, at 09:43, Hans Dembinski wrote:

Dear Daniel,

...

On 13. Nov 2017, at 17:26, Daniel Frey via Boost wrote:

I worked on other improvements, which ultimately went into its own library: https://github.com/taocpp/operators. There, I distinguish between commutative and non-commutative versions of some operators, as they allow me to provide additional optimisations (leading to fewer temporaries). This could not be done with a detection-style approach as the presence of an operator+ will not tell you whether or not it is commutative. It also plays some tricks returning rvalue-references which some people don't like (or consider dangerous), so it's not suitable for Boost.Operators.

when I was looking into operators for the histogram library, I also considered Boost.Operators and I also looked into your taocpp/operators.

I was wondering why are the rvalue-optimised versions of operators are not already part of Boost.Operators? I don't know what kind of tricks you are talking about, surely there must be rvalue-enabled versions that are standard compliant and safe, like the implementations that Richard Hodges mentioned. This seems like a straight-forward improvement of Boost.Operators that doesn't break old code. Or am I missing something?

The "problem" is that returning rvalue-references will lead to dangling references in two cases.

Before looking at those cases, consider a commutative operator+ (abbreviated version):

T operator+( const T& lhs, const T& rhs ) { T nrv( lhs ); nrv += rhs; return nrv; } // v1 T&& operator+( T&& lhs, const T& rhs ) { lhs += rhs; return std::move( lhs ); } // v2 T&& operator+( const T& lhs, T&& rhs ) { rhs += lhs; return std::move( rhs ); } // v3, remember: we assume a commutative + T&& operator+( T&& lhs, T&& rhs ) { lhs += rhs; return std::move( lhs ); } // v4

My understanding may be deficient but I would never assume that adding two values would change either of the values in any way, even if one or more of those values were rvalue references. Please tell me what I am missing and I will gladly admit my C++ ignorance in this matter if that is the case. snipped...