On 13-11-17 16:05, Richard Hodges via Boost wrote:

of course I mean:

I'm pretty sure you made a mistake

I am working on a proposal for the next committee meeting that would generate more of these operators. We recently voted in a feature for the comparison operators: the user defines `operator<=>` and gets all current comparison operators generated automatically. I will be sure to post my paper to this list for feedback prior to the mailing deadline. My paper will include a fairly comprehensive rationale for the design, which will be different from Boost.Operators. It has the advantage of needing only to work with code built against the latest standard, and it has language support, and it has the "disadvantage" of being done by default instead of being explicitly requested by the user, which obviously has slightly different design constraints. On Mon, Nov 13, 2017 at 9:46 AM, Daniel Frey via Boost < boost@lists.boost.org> wrote:

...

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

...

On 13. Nov 2017, at 15:20, Beman Dawes via Boost wrote:

Peter Sommerlad, committee member and C++Now presenter who often proposes additions to fill in holes in the standard library, asked me:

Are you aware of anybody who tried to provide a boost::operators style of automatically providing additional operators with a single base class that through SFINAE injects all possible operators based on the ones defined in the template parameter? This won't give you the control of the current boost::operators, but would be much easier to teach.

I'm the current maintainer of Boost.Operators and I heard about anyone working on that.

Above sentence is missing a "haven't": I haven't heard of anyone working on that.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Here is the initial wording of my proposal for the C++ standardization committee on generating more operators by default. I welcome any feedback. I intend to present this at the next meeting in March. https://github.com/davidstone/isocpp/blob/master/generate-operators.md On Mon, Nov 13, 2017 at 8:38 PM, David Stone wrote:

I am working on a proposal for the next committee meeting that would generate more of these operators. We recently voted in a feature for the comparison operators: the user defines `operator<=>` and gets all current comparison operators generated automatically. I will be sure to post my paper to this list for feedback prior to the mailing deadline. My paper will include a fairly comprehensive rationale for the design, which will be different from Boost.Operators. It has the advantage of needing only to work with code built against the latest standard, and it has language support, and it has the "disadvantage" of being done by default instead of being explicitly requested by the user, which obviously has slightly different design constraints.

Le 19/11/2017 à 06:22, David Stone via Boost a écrit :

Here is the initial wording of my proposal for the C++ standardization committee on generating more operators by default. I welcome any feedback. I intend to present this at the next meeting in March.

https://github.com/davidstone/isocpp/blob/master/generate-operators.md

Hi David, thanks for sharing. I believe that we shouldn't generate operations individually. We could generate some operations given a minimal definition set for a specific concept. As you note on your paper  C++ operators are overloaded on different concepts. We need the concept in order to know what do we want to generate. I have a lot of cases where operator += must be derived of operator+. But I have also cases where the compiler could generate an optimal code defining operator + in function of operator+=. When we define operator +, very often we want also operator++.  And sometime we don't want it. I'm not for having a language that generates more functions by default without opt-in. It is quite complex for a lot of people to imagine what they don't see. I want to see in the code that we are asking for the derivation of some operations given we provide some other. This is what Haskell deriving construct is for. With Template Haskell you can describe how this operation are derived. This is something we could have with the current direction of meta programming. I believe the paper is missing concrete examples that could apply to the standard, and seen the operators that could be derived in each case and with which semantic. I agree with the  comments of Daniel Frey. operator+ for strings i snot the good example, as it is not commutative. see operator++ as x+= 1 need a value 1 and seen -a as 0 - a needs a value 0. These have a sense on certain kind of types. So the solution consists in identifying the kind of types where this could be applied. |a - b| is theoretically equivalent to |a + -b only when b define -b without overflow, isn't it? Could you elaborate on the following sentence "||Even if that negation is well defined, there still may be overflow; consider |ptr - 1U|: we rewrote that to be |ptr + -1U|, the pointer arithmetic would overflow." |Could you show some examples (in the standard) where seen |lhs->rhs| as |(*lhs).rhs would reduce the standard wording? Some additional non-standard examples?| I don't see a flat map as a random access container, but maybe I'm missing something evident. Note that operator <=> return type implies the operation we want to derive and its implementation. While I find the approach interesting, I believe also it is a hack, it doesn't scale. We need a more generic mechanism to generate operations. On what concern the original post, and waiting for meta in the language (reflection/reification), we can define those using CRTP in Boost. But I will be against doing it without associating them to a concept. If we replace the spaceship operator <==> by a `order::compare` function we are able to define using CRTP the associated operations. We don't need a language change. Best, Vicente

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 now consider using it: const T t1, t2, t3, t4; // some values const T t = t1 + ( t2 + t3 ) + t4; The last line creates a temporary T for t2+t3 with v1, then calls v3 which calls += on the temporary, then v2 which again calls += on the temporary. Finally, the temporary is moved into t. So far, so good: Intermediate temporaries are only destroyed at the end of a full expression. This also means, that calling a function will work as expected. Given: void f( const T& ); // some function which wants above T calling f( t1 + ( t2 + t3 ) + t4 ); // fine, creates a single temporary works as it should. Now for the two cases where you can create a dangling reference: a) Explicitly binding to a reference "to prolong the lifetime of the temporary". This happens if you write const T& t = t1 + ( t2 + t3 ) + t4; As the last operator+ return an rvalue reference instead of an rvalue, the "const T& t =" does not bind to a temporary. The intermediate temporary created by (v2+v3) is destroyed at the end of the expression, hence t is now a dangling reference. Oops. This case is explicit, so you were basically asking for it. In my opinion it is user-error, since you expected a temporary but you haven't checked. Some people disagree and say that every class must make sure that this always works - basically forcing methods (especially operators) to always return an ralue / a temporary. This would effectively disallow these optimisations. As I can not know whether people used this in existing code, it is also not backwards compatible. This is the reason why I decided to put this into a new library and kept it out of Boost.Operators. b) The second case is implicit: Using a range-based for loop. Consider T being a container (or container-like) class and: for ( const auto& element : t1 + ( t2 + t3 ) + t4 ) { ... } This will also not work as the intermediate temporary created by (t2+t3) and which is passed to the range-based for loop is destroyed *before* the loop is executed. A solution is to actually store the value first: const auto t = t1 + ( t2 + t3 ) + t4; for ( const auto& element : t ) { ... } or maybe with C++20: for ( const auto t = t1 + ( t2 + t3 ) + t4; const auto& element : t ) { ... } // Yuck. Why?? I still think that a range-based for loop should treat the expression similar to a function call, the intermediate temporaries should only be destroyed at the end of the full loop. Sadly, all my attempts to convince others lead to nowhere. I hope this explains what I have done, why I chose to put it in its own library and not into Boost.Operators and what is controversial about it. Best regards, Daniel

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.

If you pass in an rvalue reference, you *do* expect it to be modified and you do not expect it to be accessible afterwards. Given: void f( std::vector<int>&& v ) { ... } and calling std::vector< int > v = ...; f(v); why do you expect that v has not been changed or that you can still use it? Even "adding" the values doesn't change that. If you give me an rvalue reference, I'm (mostly) free to destroy it in any way I like :) And yes, in a moved-from state you are still allowed to re-assign the value. So, I think I am expecting users of those operators (taocpp/operators) to use value-semantics from a user's perspective. You don't write int r = std::move(1) + std::move(2); just because you don't need 1 and 2 afterwards.

On 14. Nov 2017, at 22:32, Edward Diener via Boost wrote:

On 11/14/2017 2:35 PM, Daniel Frey via Boost wrote:

...

...

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. If you pass in an rvalue reference, you *do* expect it to be modified and you do not expect it to be accessible afterwards.

OK, Point conceded.

...

Given: void f( std::vector<int>&& v ) { ... } and calling std::vector< int > v = ...; f(v);

I think you meant

f(std::move(v));

D'oh! Of course. Thanks for reading what I meant instead of reading what I wrote :)

On 15. Nov 2017, at 01:35, Niall Douglas via Boost wrote:

...

If you pass in an rvalue reference, you *do* expect it to be modified and you do not expect it to be accessible afterwards.

That's only an until-so-far STL convention.

In my own code I treat rvalue references as "this may or may not be consumed" parameter. So the function may consume the input wholly, leaving it in some zombie state. Or it may leave it as is. Obviously the return type says what happened.

OK, I should have said you do have to expect that the value might be modified. But in the general case, you won't know if any function taking an rvalue-reference will or will not modify / move it. Only if it is explicitly documented (or if you have control over it), you can know. And documentation is not checked by the compiler.

This lets you write filtering functions such as:

SomeObj foo. filter_a(std::move(foo)); filter_b(std::move(foo)); filter_c(std::move(foo)); filter_d(std::move(foo));

For this example this might work, but you can not use this kind of thinking in general or force it on anyone.

In case anyone thinks I am being weird on this, I was taught to think of rvalue ref parameter inputs this way by Howard Hinnant. It's been a useful technique to know. I just wish clang-tidy didn't warn on this technique so readily.

I wonder why you don't just pass in a lvalue-reference. You can still modify the value in one of those functions and the remaining state should be visible to the following functions just like before, no?

On 11/15/17 03:04, Gavin Lambert via Boost wrote:

Given that NRVO is mandatory now, <snip>

It is? Since when? AFAIK C++17 makes RVO mandatory, but not NRVO. Thanks, Gevorg

Dear Gavin,

On 15. Nov 2017, at 07:58, Gavin Lambert via Boost wrote:

On 15/11/2017 19:27, Gevorg Voskanyan wrote:

...

On 11/15/17 03:04, Gavin Lambert wrote:

...

Given that NRVO is mandatory now, <snip> It is? Since when? AFAIK C++17 makes RVO mandatory, but not NRVO.

True, I was thinking of a different case and misspoke. The rest of the post still stands though; any optimiser worth its salt should be able to apply NVRO there and elide most if not all of the copies, and it should be safer without sacrificing performance.

Granted that I have not actually measured this, and so might end up surprised.

I played around with the two versions of operators, the one returning rvalue references and the ones you suggested that might apply NVRO. https://github.com/HDembinski/testing_grounds/blob/master/test/test_fast_ope... https://github.com/HDembinski/testing_grounds/blob/master/test/test_fast_ope... On Apple Clang 9.0.0, NVRO does not seem to work, but perhaps I am not tracking this correctly. I use this class to track copying calls: static unsigned ctor_count = 0; struct A { A() { ++ctor_count; } A(const A&) { ++ctor_count; } A& operator=(const A&) { ++ctor_count; return *this; } A(A&&) {} A& operator=(A&&) { return *this; } A& operator+=(const A&) { return *this; } }; Best regards, Hans

For those interested, here's a test program with which you can play. The results are, respectively, 0+1, 3+0, 0+3, 0+3, 0+0. #include <iostream> #include <utility> int copies = 0; int moves = 0; struct T { int v_; explicit T( int v ): v_( v ) {} T( T const& t ): v_( t.v_ ) { ++copies; } T( T&& t ): v_( t.v_ ) { ++moves; } T& operator+=( T const& t ) { v_ += t.v_; return *this; } }; 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 /* 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 lhs; } // v2 T operator+( const T& lhs, T&& rhs ) { rhs += lhs; return rhs; } // v3, remember: we assume a commutative + T operator+( T&& lhs, T&& rhs ) { lhs += rhs; return lhs; } // v4 */ /* 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 */ /* T operator+( T lhs, const T& rhs ) { lhs += rhs; return lhs; } */ /* T operator+( T const & lhs, T const & rhs ) { return T( lhs.v_ + rhs.v_ ); } */ int main() { T t = T(1) + T(2) + T(3) + T(4); std::cout << "T(" << t.v_ << "): " << copies << " copies, " << moves << " moves\n"; }

Daniel Frey wrote:

...

On 15. Nov 2017, at 17:05, Peter Dimov via Boost wrote:

For those interested, here's a test program with which you can play. The results are, respectively, 0+1, 3+0, 0+3, 0+3, 0+0.

Nice, thanks for that. But the 0+0 is slightly misleading, as you don't copy the value with a copy-ctor, but you initialise a new value directly - this should count as well, especially thinking of cases like a matrix-like class with, say, an array of NxM elements as a direct member.

True, it does not count the constructions. These are 4 for the += based variations and 7 for the plain op+. It's all slightly misleading anyway, because for the small matrix case the copy/move constructors don't actually have side effects and therefore get optimized out; they are only relevant in the case of something like std::string where copy/move aren't defaulted. Also, the results for T t1(1), t2(2), t3(3), t4(4); T t = t1 + t2 + t3 + t4; are slightly different. 4+1+1, 4+3+0, 4+1+2, 4+1+3, 7+0+0.

On 16. Nov 2017, at 02:39, Gavin Lambert via Boost wrote:

On 16/11/2017 05:41, Peter Dimov wrote:

...

It's all slightly misleading anyway, because for the small matrix case the copy/move constructors don't actually have side effects and therefore get optimized out; they are only relevant in the case of something like std::string where copy/move aren't defaulted.

That was my point; your test code doesn't test copy elision because your constructors have side effects, so can't be elided.

Copy elision (RVO/NRVO) is part of the standard only because it allows the compiler to elide a copy-ctor even if it has side-effects. In other words, if the compiler would apply copy elision, you would see the side-effects to change.