Boost logo

Boost :

Subject: Re: [boost] [operators] A modern SFINAE-based version of boost::operators?
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-11-13 16:14:58


On 11/13/17 6:20 AM, Beman Dawes via Boost wrote:
> Peter Sommerlad, committee member and C++Now presenter who often proposes
> additions to fill in holes in the standard library, asked me:
>
> Are you aware of anybody who tried to provide a boost::operators style of
> automatically providing additional operators with a single base class that
> through SFINAE injects all possible operators based on the ones defined in
> the template parameter? This won't give you the control of the current
> boost::operators, but would be much easier to teach.
>
> For example
>
> struct Me : make_operators_for<Me>{
> Me& operator+=(Me const&); // You get +
> bool operator<(Me const&) const; // You get all relops (<=> will make that
> obsolete)
> Me& operator++(); // you get postfix
> //etc.
> };
>
> Today we have the facilities and compilers to make that happen.
>
> What do you think? Who should I ask?
>
> Anyone doing any work on operators or have any thoughts about updating
> boost::operators?

I'm pretty familiar with this. I used boost operators to create
BOOST_STRONG_TYPE which a number of people liked. As time went on, and
I wanted to make the serialization library more bullet proof, I fell out
of love with it because it generated all the numeric operators, thus
admitting errors (such as multiplying two object ids) I would have
preferred to be trapped at compile time. So I eventually removed the
usage of it.

This kind of thinking eventually has led me to my current major project
and likely last hurrah: my "Algebra" library. This was the subject of
my presentation at CppCon 2016 “C++, Abstract Algebra and Practical
Applications" https://www.youtube.com/watch?v=632a-DMM5J0

I spent significant amount of time looking at boost operators and other
similar ideas for "automatically" adding "missing" operators. The
problem which arises is trying to automatically determine which
operators are missing. In the presentation I used the example of a
quantity length. Given a length type and a corresponding + operator it
makes sense to "generate" a += operator. But what about - ? one can
take the difference of two lengths - but that operation is not
guaranteed to yield a valid value for length - so the automatic
operations wouldn't be a good choice. A similar type - Position - would
have no problem with an automatically generated - operator. So I
concluded that automatically generating "related" operators would turn
in to a minefield littered with lots of special cases, exceptions, weird
rules and a documentation nightmare. I've turned to the implementation
of concepts of abstract algebra in terms of C++ as way to systematize
the selection, declaration and definition of operators in C++ for
specific types. It is currently a work in progress.

The ultimate goal is to be able to specify algebraic types with a set of
attributes which would create all appropriate operators while trapping
any inappropriate usage.

Such a facility, in conjunction with Boost Units (enhanced with improved
easier to use documentation and perhaps some corresponding tweaks) would
provide the base for writing provably correct programs. These programs
would be written in terms of these strongly defined types such that it
is almost impossible to get wrong. (of course these would be a bitch to
compile - writing then normal crappy code is really fast and fun after
all).

An offshoot of this, which has been incredibly absorbing, is the safe
numerics library whose implemenation requires some of the ideas
mentioned above. This is proceeding apace - it has required more time
and effort than anticipated.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk