Boost logo

Boost :

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2013-04-26 00:44:08

On Thu, 25 Apr 2013, Daniel Frey wrote:

> On 25.04.2013, at 23:04, Marc Glisse <marc.glisse_at_[hidden]> wrote:
>> In any case, it could be nice to have the helpers in both directions.
>> One addable that implements + from +=, and one addable_reverse that
>> implements += in terms of + (you could try a+=b as a=move(a)+b maybe?).
> Given that I currently have 4 overloads for operator+ that usually need
> a single operator+= to provide efficient operations, I'd like to see how
> this could work with the reverse and the use-case. Why would anyone want
> to implement operator+ and generate operator+= from it? And even without
> a detailed analysis *this=std::move(*this)+value looks and feels just
> wrong. Seeing something like this in the companies code-base would
> probably make me go to the author and ask him to fix it by reversing it.
> :) Of course it could be my lack of imagination and I'd be happy to see
> an example where it is the obvious/right approach.

In a number of cases, operations can't work in place (need a larger
buffer, object is reference counted, etc). Copying one argument to apply
an in-place operation to it is a waste of time, you are going to create a
new object for the result anyway. Even in the ref-counted case, the
copying may be hard for the compiler to optimize away if the counter is
atomic. And if you care more about constexpr than performance,
implementing + yourself is a must, but you may still want to avoid the
one-liner to implement the corresponding += (ok, that sounds a bit weak).
I guess I am mostly thinking of cases where only one of the + overloads
matters, the one with const&, const&.

Maybe more relevant would be a way for the user to write himself += and
+(const&, const&) and let boost add only the other 3 overloads based on

Marc Glisse

Boost list run by bdawes at, gregod at, cpdaniel at, john at