Re: [boost] a safe integer library

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...

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 !