Subject: Re: [boost] a safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-01-13 15:32:01
On 1/13/16 10:07 AM, Brook Milligan wrote:
> Perhaps this (perceived lack of interest) is the fundamental issue.
It is a big issue.
> we need much _better_ support for this sort of thing, ...
> so I am sorry that you perceive little interest...
<rant - feel free to skip>
well, its a perception grounded on experience. I proposed a
presentation at CPPCon 2015 on this library and it was rejected by a
strong consensus of reviewers on the basis that it wasn't an interesting
subject. The talk I did give on a related subject - Using Boost Units
to write correct code - had 5 attendees. I posted to the appropriate
C++ Standard Library list and it generated on comment. Since I made the
library public most initial comments have been along the lines of "if
you need something like this - you're not writing your code correctly".
That is, there is something about this that seems to many people to be
fundamentally wrong.
Yet to me - it's current computer arithmetic which is fundamentally
wrong. It has a syntax which suggests that it's equivalent to "normal"
arithmetic, but silently breaks the rules of that arithmetic. And note
that this is not a C++/C issue - all the current languages have this
problem.
</rant>
> I realize your focus to date has been on native integers, so the
> following clearly represents an extension to your intent for the
> current implementation, but not to your motivation. I will mention
> it, because I feel it indicates that your library already has almost
> everything needed and that very little extra would be needed for
> generality. I say this being fully aware of the iteration loop that
> you have been involved with and have described earlier.
I think you're too optimistic. Damian Vicino has been working on safe
float. The first thing we've discovered is that it has an entirely
separate set of issues come to fore. Our view is that this is not going
to be just a question just extending the safe integer library.
> In the course of this discussion I have looked through the code quite
> a bit and it seems that there is relatively little that limits your
> library to integers. Here is where I see the dependence on integer
> types:
> - Reliance on std::numeric_limits for the bounds. A trivial change
> to numeric/convertible/bounds.hpp from the Numeric.Conversion library
> will make it constexpr-capable and allow a completely generic
> definition of bounds.
I spend a lot of time looking at Boost Convert documentation and
failed to understand what it does and how do use it. I may or may not
have looked at the code - I don't remember. I leveraged on the
std::numeric_limits because:
a) it had what I needed.
b) its delivered with every C++ compiler in a way which is adjusted to
the target environment. That is I don't have figure out for every
platform what the size of an int is.
c) It is extendable. That is, all safe types have their own
numeric/limits class - even those which are created on the stack during
the composition of binary operators into more complex arithmetic
expressions.
d) It is extendable to other integer like types. I would expect to see
a numeric limits class for money, and by extension for safe<money>
e) it's there - using diminishes the code I have to write and maintain.
f) it's public - so there is a chance that if someone makes another
integer like type that I don't anticipate - there's a chance the safe
integer library might work with it - or at least diminish the effort to
make that new type a safe one.
e) So it presents a generic interface to meta data about numeric types.
Its a good basis for such a library.
> switching the references to std::numeric_limits<T>.min() and
> std::numeric_limits<T>::max() to bounds<T>::lowest() and
> bounds<T>::highest().
OK maybe I misread your comment. I thought you were referring to boost
convert. I don't remember anything about boost numeric bounds. I'm
sure I looked at at it as I searched all of boost - and a bunch more
stuff - in order to diminish my task. as I said - std::numeric_limits
does everything that's needed, works, is maintained and is free.
> - Ignoring issues like denormalization. Clearly this is irrelevant
> for integral types, but not for floating point. Likewise, a full set
> of policies for floating point would need to be richer. However, I
> feel that a significant collection of use cases are covered by just
> considering the range and ignoring denormalization. It would be
> unfortunate to block useful advances for wont of complete generic
> policies for floating point.
useful - but more to it than meets the eye. see above.
> Otherwise, I am not seeing (or at least remembering) anything that is
> really dependent on integral types.
LOL - look harder
> A great step forward would be to act on these observations and take
> your great foundation one more step so that it is much more generic.
Feel free to take your best shot !