On Tue, Oct 4, 2011 at 8:02 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
What's the idea exactly?
implement operator+ in terms of operator+=? That's not always suitable.
Yes, it's not always suitable, but that's true of the operators in Boost.Operators already. If the definition of operators provided by Boost.Operators are not suitable for a given type, that person just shouldn't use that helper base, just as is done now. The manner in which the operators are implemented is well defined in the documentation along with requirements. The presence of r-value references only opens up more efficient implementations that can be automatically created, again, given that your type obeys certain requirements (addition must be commutative, etc.). Anyway, yes, it would implement + in terms of += just as is done now, but with r-value references you can potentially reuse one of the operands without copying it. The only question I have is should the return type be a value type or an r-value reference type (there are subtle differences for a user). A quick synopsis of what would likely be generated: type operator +( type const&, type const& ) or an equivalent with copies is defined automatically as normal type operator +( type&&, type const& ) is defined to use += on the first argument which is then move-returned type operator +( type const& left, type&& right ) is defined as return std::move( right ) + left type operator +( type&& left, type&& right ) required for disambiguation and just returns std::move( left ) + right If the operations return "type&&" instead of "type", they can potentially be more efficient, but I'm a little cautious to do that without giving it some thought because the choice implies subtle differences. I'm sure Daniel has already taken this all into consideration. -- -Matt Calabrese