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

On Thu, 25 Apr 2013, Daniel Frey wrote:

On 25.04.2013, at 13:19, Daryle Walker wrote:

...

...

3) Support for constexpr if this is applicable at all. I haven't found the time to properly research it yet.

I've discussed this somewhere, but this library and constexpr are incompatible. The dependency between operator?? and operator??= is backwards to what constexpr needs. [...] You can compose the regular version of an operator in a constexpr way if you have the right initialization. But the compound-assignment operators are inherently mutating, so they can never be constexpr. Defining the regular versions in terms of the compound-assignment ones bars them from being constexpr. You can reverse the dependencies to save code.

Thanks Daryle, that really helped me to get a clearer picture on the topic. I think I only have two questions left:

1) How could "reverse the dependencies" save code? Could you elaborate, please?

You want to write only one of += and +. Omitting + (as boost.operators currently allows) saves about the same as omitting += (easier on constexpr, but possibly slower for some applications).

2) Given a set of non-constexpr overloads, could the user add even more overloads for constexpr and what is required for this to work? Example:

struct X : private df::commutative_addable< X > { X& operator+=( const X& ); };

constexpr X operator+( constexpr X lhs, constexpr X rhs ) {…}

is the above possible? Are there problems/conflicts? What are the requirements for the non-constexpr overloads and the signature/requirements for the user-defined constexpr-overload to play together nicely?

That's not how constexpr works, there is no overloading on whether the arguments are constexpr. In C++14, as far as I can tell, you'll be able to add constexpr to += no problem, so for boost operators that means you can add a macro in front of every function, that you'll define as constexpr when you are ready. But in C++11, constexpr functions are essentially pure. They take constants and return a constant. That means += can't be constexpr, and a + implemented in terms of += can't either. On the other hand, one can implement a constexpr + directly, and implement += (not constexpr) in terms of that +. That seems to be what Daryle is suggesting. 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?). -- Marc Glisse