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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-04-26 11:49:41

On Thu, Apr 25, 2013 at 9:44 PM, Marc Glisse <marc.glisse_at_[hidden]> wrote:

> On Thu, 25 Apr 2013, Daniel Frey wrote:
>
>  On 25.04.2013, at 23:04, Marc Glisse <marc.glisse_at_[hidden]> wrote:
>>
> [...]

> 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 +=?

That's an interesting idea.

- Jeff