On 12/10/15 9:30 AM, Paul A. Bristow wrote:
Detecting and handling overflow (and underflow) is certainly something is a big missing item with C/C++.
But I'm not sure that your proposal is radical enough.
This is the first time I remember being accused of this.
I'm sure that your solution will work (though I haven't been able to study it in detail yet),
I much appreciate your vote of confidence.
but if you allow definition of a safe minimum and maximum then I fear that you are paying the big cost in speed
nope, you've got it backwards. Consider the following example. You have a variable stored in an int8_t. You can absolutely know that if you square this variable, it can never produce an arithmetically correct result - even in C++. So there is zero overhead in proving that your program can never fail. One of the main features of the libraries implementation is that it carries range information around with the type. When a type is used in an expression, compile time range arithmetic is used to determine whether or not it's necessary to do any runtime checking. So such runtime checking is performed only when it is actually necessary. that comes from not using the built-in carry bit provided by all the processors that we care about. In cases where runtime checking is necessary, the library implements this is a portable way. But there's no reason one couldn't conditionally specialize the functions to implement this functionality in a manner which takes advantage of any special hardware facilities.
So I fear it is premature until we have solved the problem of detecting overflow and underflow efficiently.
Just the opposite. Now is the time to use C++ to make the problem smaller and create a "drop in" interface so that any future "solutions" to the problem can be available without having to recode our programs. That is, we want to augment/enhance C++ through libraries such as this to decouple our programs from specific machine features while maintaining the ability to gain maximal runtime efficiency. So the library has several aspects: a) creating types which carry their ranges around with them through expressions. b) using operator overloading to make usage of the library as easy as replacing your integer types with corresponding safe integer types. c) implementing runtime code to handling error generating expressions in an efficient manner. For c) I've provided a portable solution which is pretty efficient. But I'm guessing you're correct that one could do better were he to give up on portability.
Lawrence Crowl, Overflow-Detecting and Double-Wide Arithmetic Operations http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0103r0.html
I looked at these. The above discussion should make it clear I'm addressing something else here. The problem for me is not creating efficient runtime checking. The problem is to create an interface which can incorporate such code while maintaining the ability to transparently code numeric algorithms. It's about decoupling the arithmetic from the hardware in way that preserves maximum efficiency.
This seems something that will allow your solution to be efficient, at least for built-in integral types?
So if you're interested in contributing: a) Consider re-implementing you're own version of "checked" operations which exploit features of this or that hardware. b) create a couple of performance tests so we can measure what the actual performance hit is. The above should make it clear that this will require a non-trivial amount of effort.
(And not everyone wants to throw exceptions - even if perhaps many think that they are mad?)
Note that the library specifies error behavior via a policy. www.blincubator.com Take care to make a distinction between the proposal to C++ standards committe http://www.rrsd.com/software_development/safe_numerics/proposal.pdf (which is less ambitious aimed at whimpier programmers) and the proposal for Boost www.blincubator.com ( which is for glutons for punishment such as ourselves). Robert Ramey