-----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]; public: 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 > inline 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. [TRUNCATE]
Daryle W.