Treating the abusive unsigned syndrome

[Michel Fortin]

On 2008-11-26 13:30:30 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> 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
michel.fortin at michelf.com
http://michelf.com/