Boost logo

Boost :

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Daryle Walker (darylew_at_[hidden])
Date: 2013-04-25 07:19:13

-----Original Message-----
From: Daniel Frey
Sent: Monday, April 22, 2013 3:43 PM

> Hello,
> for a long time there hasn't been any significant update of
> Boost.Operators and I had an easy job being its maintainer for the past
> 10+ years. I guess that will change soon. :)

> I would like to discuss the future of Boost.Operators, as several issues
> and options have piled up in the past. Here are some points to take into
> account:

> 1) Support for rvalue references to generate fewer temporaries. (where
> available)
> 2) Support for noexcept. (where available)
> 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.

    template < typename T >
    class my_complex {
        T d[2];
        my_complex( r = T{}, I = T{} ) : d{r, i} {}

    template < typename T >
    inline constexpr
    my_complex<T> operator/( my_complex<T> x, T y )
    { return my_complex{x.real() / y, x.imag() / y}; }

    template < typename T >
    my_complex<T> & operator/=( my_complex<T> &x, T y )
    { return x = x / y; }

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.

> 4) Allow dedicated commutative and non-commutative versions for several
> operators, leading to fewer temporaries for commutative versions in
> several cases.
> 5) Remove work-arounds for ancient compilers, general cleanup.

Daryle W.

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