On 2008-11-26 13:30:30 -0500, Andrei Alexandrescu
<[EMAIL PROTECTED]> said:
Well let's look closer at this. Consider a system in which the current
rules are in vigor, plus the overflow check for uint.
auto i = arr.length - offset1 + offset2;
Although the context makes it clear that offset1 < offset2 and
therefore i is within range and won't overflow, the poor code generator
has no choice but insert checks throughout. Even though the entire
expression is always correct, it will dynamically fail on the way to
its correct form.
That's because you're relying on a specific behaviour for overflows and
that changes with range checking. True: in some cases the values going
circular is desirable. But in this specific case I'd say it'd be better
to just add parenthesis at the right place, or change the order of the
arguments to avoid overflow. Avoiding overflows is a good practice in
general. The only reason it doesn't bite here is because you're limited
to additions and subtractions.
If you dislike the compiler checking for overflows, just tell it not to
check. That's why we need a compiler switch. Perhaps it'd be good to
have a pragma to disable those checks for specific pieces of code too.
Contrast with the proposed system in which the expression will not
compile. They will indeed require the user to somewhat redundantly
insert guides for operations, but during compilation, not through
runtime failure.
If you're just adding a special rule to prevent the result of
substractions of unsigned values to be put into auto variables, I'm not
terribly against that. I'm just unconvinced of its usefullness.
--
Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/
