int opEquals(Object), and other legacy ints

[kris]

Frits van Bommel wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> Stewart Gordon wrote:
>>>
>>>> But if the function only tries to return 0 or 1 anyway, then what 
>>>> difference does it make?  At the moment, I can't think of an example 
>>>> of equality testing that can be made more efficient by being allowed 
>>>> to return a value other than 0 or 1.
>>>
>>>
>>>
>>> I can. (a == b), where a and b are ints, can be implemented as (a - 
>>> b), and the result is int 0 for equality, int !=0 for inequality.
>>
>>
>>
>> So, why not treat false as 0, and true as not 0?  That way, it works 
>> just the same as the "int" version does (and comparing/testing against 
>> zero doesn't hit the address-bus). Yes, I can see some potential for 
>> concern there; but is there anything insurmountable?
> 
> 
> Then what would happen if a and b differ by, say, 256? Remember, an int 
> is 4 bytes, a bool is only 1.

Sure, but it's generally more efficient to do all logical and arithmetic 
operations in the native width of the device anyway ~ generally 32bits 
for current D compilers.

If you're talking about issues related to actually storing a bool 
result, then that's part of the "concerns" noted above. Bool values 
derived in certains ways may need to be folded for storage, but not for 
testing. The subtraction case above may be included in that group, but 
testing should still only require a compare against zero (for both true 
and false). I'm suggesting only that zero values should *always* be used 
to test for 'truth' ~ never 1, or 255, or any value other than zero. 
Anywhere the keyword "true" is used (or implied) for comparative 
purposes, test against zero and invert the jmp-condition instead. If 
that's not done already, it would probably speed things up in many cases.