Re: [boost] [operators] The future

Subject: Re: [boost] [operators] The future
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2011-10-04 11:38:58

On Tue, Oct 4, 2011 at 8:02 AM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> 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