On 12/16/15 11:16 PM, David Stone wrote:
I have written a similar library (http://doublewise.net/c++/bounded/), and I have a few questions about your implementation.
I'm very aware of this. I attended your excellent presentation of you bounded integer library at C++Now 2014. I've also referenced your library in the documentation for safe_numeric. I was working on the safe numeric library at the time so that's why I was interested.
You have a few policies for what to do on overflow. In particular, I see you have throw_exception and trap_exception. trap_exception provides a compile-time error instead of a run-time error. Could you explain this a little bit more?
As we speak I'm putting the final touches on this. Basically it traps at compile time if an exception might occur. That is if it cannot be known at compile time the the operation cannot fail - a compile time error is invoked.
In my library, conversions for which the type is definitely in range (for instance, [1, 6] assigned to [0, 10]) are implicit and no check is performed.
this is similar
Conversions for which the type is possibly in range are explicit and the policy is applied (run-time check).
hard to tell, but might be similar.
Conversions for which the type is definitely out of range are a compile-time error,
In my case this is always an error.
unless the overflow policy says that overflow is not an error.
But one could specify his own custom policy which ignored such an error. BUT I'm not sure how useful it would be as it would apply to the type - not the value so it would be hard to use as one might intend. I do have a policy to ignore errors. But I haven't tested it. I'm thinking I should eliminate it as it would defeat the whole purpose of the library.
Your overflow policies all seem to assume overflow is error.
It's not so much the policies - it's more my vision for the library usage. The driving purpose is to be able to know that one's code implements correct arithmetic. So my basic premise is that an overflow is an error.
How difficult would it be to add in the ability to provide 'clamping' or 'saturation' behavior? If you go below the min, set the value to the min, and if you go above the max, set to the max.
I never considered this, and from what I know about the design of the library, I don't think it would be practical to implement on top of what I have now.
Similar question for a modulo policy, which gives you the same behavior as unsigned integers.
I've got a whole different view of this as well. Consider handing some other type - be it a wall known arithmetic type such as modulo integers or some special type like money. My approach would be: a) make your class - say a clock (modulo 60) or money class b) declare safe<money> and you'll be done! right - not quite. But not that far off. I have a couple of "back ends" which handle compile time integer<T> for any T and checked arithmetic which is templated on T. Currently it works only for integer types. So one would have to specialize on checked<money> which would be defined in terms of checked<T> since money would be defined in terms of some integer. As far as exceptions and promotions - selection of these would be independent of any particular type.
I will have more thoughts later as I read the rest of the documentation.
I'm currently putting the finishing touches on an upgrade of the code and improvement and enhancement of the documentation. The main enhancement will be a treatment of how to guarantee no errors with no runtime overhead. I expect to have a new version by monday. Robert Ramey