On 7/4/11 2:48 PM, bearophile wrote:
Steven Schveighoffer:
To the point -- lots of existing D and C code uses the properties
of integer overflow. If integer overflow is assumed to be an
error, then that code is broken, even though the code *expects*
overflow to occur, and in fact might *depend* on it occurring.
In this case you wrap the code in something that allows it to
overflow without errors, like:
unsafe(overflows) { // code here }
This approach has a number of issues. First, addressing transitivity is
difficult. If the code in such a scope calls a function, either every
function has two versions, or chooses one way to go about it. Each
choice has obvious drawbacks.
Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts the
burden on the coder. So code will be littered with amends, yet still be
overall slower. This feature has very poor scalability.
------------------------
Andrei:
This and others (zero- vs. one-based indexing, closed vs. open
intervals etc.) are issues with well-understood tradeoffs that
could go either way.<
Integral overflows are not the same thing as indexing and intervals.
Of course they're not the same thing. Commonalities and differences.
Such last two are equal ways to write the same thing, while overflows
are a way to spot a class of bugs in code.
Well they also are a solid way to slow down all code.
Making a choice in such matters becomes part of a language's
ethos.<
Right, and I think D Zen is pro-safety.
You are using a different version of safety than D does. D defines very
precisely safety as memory safety. Your definition is larger, less
precise, and more ad-hoc.
After a while it becomes clear that rehashing such matters without
qualitatively new arguments is futile.<
I have answered because you have said wrong things. You have
implicitly said that good overflow tests are doable with library
code, and I have explained why you are wrong. This isn't futile.
Probably one good thing to get past is the attitude that in such a
discussion the other is "wrong". These are simple matters of which
understanding does not require any amount of special talent or
competence. So the first step is to understand that some may actually
value a different choice with different consequences than yours because
they find the costs unacceptable. As someone who makes numerous posts
and bug reports regarding speed of D code, you should definitely have
more appreciation for that view.
Andrei
