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