Why does Object.opEquals return int

[Bruno Medeiros]

Bill Baxter wrote:
> Bruno Medeiros wrote:
>> Stewart Gordon wrote:
>>
>>> Anders F Björklund wrote:
>>>
>>>> Kristian Kilpi wrote:
>>>>
>>>>> So the original question remains: why 'opEquals' returns int?
>>>>
>>>>
>>>> Walter says it is for performance reason, when e.g. sorting...
>>>>
>>>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html
>>>
>>>
>>> I'm still not convinced that there's any way that opEquals can be 
>>> made more efficient by returning int instead of bool.
>>>
>>> Stewart.
>>>
>>
>> Even more so due to the SETE instruction (which gcc uses) and makes 
>> converting to a bool after a comparison just as fast as getting an 
>> int. I wish Walter would comment on that, because, in the point that 
>> the discussion was left using a bool would be just as fast as an int, 
>> and I would like a lot of those functions like opEquals to return a bool.
> 
> I think it was already pointed out that instruction count doesn't tell 
> you anything cycle counts.  SETE maybe one instruction, but that doesn't 
> necessarily mean it's any faster.  I may be.  I don't know.  Just it 
> isn't a given.  Also I you're free to make your own classes return bool 
> from opCmp, it's just Object opCmp that returns int.  And note that it's 
> only for _value_ comparison of objects.
> 
> Personally I think Object.opCmp returning int is an oddity, but it pales 
> in comparison with the mixins/imports problem, the ambiguity of auto, 
> and the major bugs left in variadic templates.
> 
> --bb

On that previous discussion, a page which listed the internal clock 
counts for the instruction was linked 
(http://www.cs.tut.fi/~siponen/upros/intel/instr/sete_setz.html) where 
we can see it isn't any slower.
-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D