WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Friday, 25 July 2014 at 21:01:49 UTC, Walter Bright wrote:
> 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.

Doesn't the compiler-generated opEquals do a memcmp when it can? 
Obviously, it can't always, but in the simple POD cases (that 
don't involve floating point values anyway), it should be able to 
it.

- Jonathan M Davis