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
