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