WAT: opCmp and opEquals woes

[Walter Bright via Digitalmars-d]

On 7/25/2014 4:18 AM, Jacob Carlborg wrote:
> On 25/07/14 11:46, Jonathan M Davis wrote:
>
>> Code that worked perfectly fine before is now slower, because it's using
>> opCmp for opEquals when it wasn't before.
>
> Who says opCmp need to be slower than opEquals.

Consider:

    struct S { int a,b; }

    int opCmp(S s2) {
         return (a == s.a) ? s.b - b : s.a - a;
    }

    bool opEquals(S s2) {
         return *cast(long*)&this == *cast(long*)&s2;
    }

Because of byte ordering variations, the cast trick wouldn't work reliably for 
opCmp.

Do people do such things? Yes, since opEquals can very likely be in critical 
performance loops.