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