Re: [boost] [operators] The future of Boost.Operators

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