Length comparison

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Tue Dec 5 10:09:26 PST 2006


Don Clugston wrote:
> Frits van Bommel wrote:
>> Don Clugston wrote:
<snip>
>>> And for this reason, comparing signed variables with unsigned 
>>> variables is almost never an error (when people use 'uint', they 
>>> almost always mean 'positive int'). Detecting mismatch comparisons 
>>> with literals would be a good thing, though.
>>
>> Yes it would be a good thing if this was detected.
>> IMHO it would be an even better thing if the automatic transformation 
>> above would then be performed when such a mismatch is detected :).
> 
> But if a mismatch was detected, would there be any way to request a fast 
> comparison without introducing bugs?

Depends on what you mean by fast and what you mean by bugs ;).

Hmm...
If "a < 0 || cast(uint)a < b" isn't fast enough for your liking, then 
probably the only way to make it faster would be to eliminate the "a < 
0" part, which would require writing out "cast(uint)a < b" in full. That 
  might introduce bugs if the type of a was changed to something that 
can have values bigger than an uint can hold.
So yeah, that might be a problem.

The reality of it is of course that this change probably won't happen 
anyway, because of Walter's whole "if it looks like C, it behaves like 
C" philosophy. If he holds to that the best we can probably hope for is 
some way to express this that doesn't look like C. Maybe some new 
operators for these "safe comparison" operations...
Unless... What does the C standard say about comparing negative signed 
numbers to unsigned numbers? If the result is Undefined(TM) (or 
implementation-defined) then defining it in D would not be limited by 
this :).

Forgive me if this is all a bit too much stream-of-consciousness[1], but 
writing about things is a good way to think about them :).


[1]: Is that the right term? Not sure. Not a term I use a lot ;) 
(especially in English)



More information about the Digitalmars-d mailing list