int opEquals(Object), and other legacy ints

Stewart Gordon smjg_1998 at yahoo.com
Fri Jul 28 11:44:06 PDT 2006


xs0 wrote:
<snip>
> Well, I'm just guessing, but I think something like
> 
>  > int opEquals(Foo foo)
>  > {
>  >     return this.bar == foo.bar;
>  > }
> 
> is compiled to something like
> 
>> return this.bar-foo.bar; // 1 instruction
> 
> but if the return type is bool, it becomes
> 
>> return this.bar-foo.bar?1:0; // 3 instructions

If it does this, then there's a serious bug in the compiler.

Moreover, what's your evidence that subtracting one number from another 
might be more efficient than comparing them for equality directly?

> It's the 1/0 constraint on bools that causes the slowness, not the size 
> (stack is usually size_t-aligned anyway)

But if the function only tries to return 0 or 1 anyway, then what 
difference does it make?  At the moment, I can't think of an example of 
equality testing that can be made more efficient by being allowed to 
return a value other than 0 or 1.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.



More information about the Digitalmars-d-bugs mailing list