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

On Thu, 25 Apr 2013, Daniel Frey wrote:

On 25.04.2013, at 23:04, Marc Glisse 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