On Tue, 26 Mar 2013 14:20:30 -0400, bearophile <[email protected]>
wrote:
Steven Schveighoffer:
If we treated it as an error, then it would be very costly to
implement, every operation would have to check for overflow.
I have used similar tests and it's not very costly, not significantly
more costly than array bound tests.
Array bounds tests are removed for release code. And an array bounds test
is unequivocally an error.
In many cases, overflowing integers are not a problem, easily proven not
to occur, or are expected. Such designs would have to fight the compiler
to get efficient code if the compiler insisted on checking overflows and
possibly throwing errors.
In the meantime Clang has introduced similar run-time tests for C/C++
code. So C/C++ are now better (more modern, safer) than the D
language/official compiler in this regard.
(And Issue 4835 is about compile-time constants. CFFE is already plenty
slow, mostly because of memory allocations. Detecting overflow in
constants is not going to significantly slow down compilation, and it
has no effect on the runtime. Even GCC 4.3.4 performs such compile-time
tests.)
If CTFE did something different than real code, that would be a problem.
Again, you should be able to construct the needed types with a struct, to
use in both CTFE and real code.
The CPU does not assist in this.
The X86 CPUs have overflow and carry flags that help.
What I mean is the cost is not free. Like null pointer checks are free.
For code that is specifically designed to be very fast and is properly
designed not to experience overflow, it would be needlessly penalized.
The simple for loop:
for(int i = 0; i < 10; ++i)
would now have to deal with uselessly checking i for overflow. This could
add up quickly.
-Steve
