Boost logo

Boost :

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2013-04-25 17:04:45

On Thu, 25 Apr 2013, Daniel Frey wrote:

> On 25.04.2013, at 13:19, Daryle Walker <darylew_at_[hidden]> 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

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