Object.opEquals returns int for some reason. That means I can't do
something like:
bool func() {
...
return objA == objB;
}
(Because int can't be converted to bool automatically). Instead I have
to do something like
return (objA == objB)!=0;
Which is just looks silly.
Is there any good reason for opEquals to return an int? opCmp has to, I
understand, but opEquals has no business returning int. Is this a
holdover from the days before bool?
--bb

Object.opEquals returns int for some reason. That means I can't do
something like:
bool func() {
...
return objA == objB;
}
(Because int can't be converted to bool automatically). Instead I have
to do something like
return (objA == objB)!=0;
Which is just looks silly.
Is there any good reason for opEquals to return an int? opCmp has to, I
understand, but opEquals has no business returning int. Is this a
holdover from the days before bool?
--bb

After seeing some crashes upon comparing with null objects, I realized
what I actually want is:
return objA is objB;
So I should change my question to "Why is opEqual defined by object at
all??"
--bb

Object.opEquals returns int for some reason. That means I can't do
something like:
bool func() {
...
return objA == objB;
}
(Because int can't be converted to bool automatically). Instead I have
to do something like
return (objA == objB)!=0;
Which is just looks silly.
Is there any good reason for opEquals to return an int? opCmp has to,
I understand, but opEquals has no business returning int. Is this a
holdover from the days before bool?
--bb

After seeing some crashes upon comparing with null objects, I realized
what I actually want is:
return objA is objB;
So I should change my question to "Why is opEqual defined by object at
all??"
--bb

The "is" operator just compares for references/pointers, not object
equality.

Thanks for the link. Not sure how it matters when sorting, because then
you'd be using opCmp. I'd certainly find the performance argument more
convincing with some actual performance measurements to back it up, but
oh well. Much bigger fish to fry out there than the return value of opCmp.
--bb

Thanks for the link. Not sure how it matters when sorting, because then
you'd be using opCmp. I'd certainly find the performance argument more
convincing with some actual performance measurements to back it up, but
oh well. Much bigger fish to fry out there than the return value of opCmp.
--bb

The main use seems to be for AA's, along with toHash(). At least that's what I
recall...
been a good while since I trek'd through the internals. Note, however, that
yes it does
hearken from the days before we had the current 'bool' type (ah yes, the days
of 'bit')
and it was indeed for performance reasons.
BUT, now that we have 'bool', I see no apparent reason why it /shouldn't/ be a
bool.
-- Chris Nicholson-Sauls

Well, I don't like it ;) , even though more speed is good. 'opEquals' have
to be used in pretty simple algorithms to gain speed advantage over bool.
I mean, for example, a loop consist of 100 instructions, and we're talking
here saving 1 - 3 instructions per one loop. If looping takes 1 min, we
save 1.8 secs at maximum... And I think loops etc nowadays contain more
likely thousands of instructions instead of hundreds. Of course, very low
level stuff is good to be as fast as possible, but if you need to save
these 1 - 3 instructions, then you should use assembly anyway; I'm pretty
sure that no compiler produces optimal assembly code. ;)
So, maybe the actual reason of this is that chaging the return type would
break old code?
I'm just afraid what public will think of this.

I'm still not convinced that there's any way that opEquals can be made
more efficient by returning int instead of bool.
Stewart.

Yep. Lets consider the following simple loop, which proves the point, I
think:
for(i = 0; i < Y; i++)
X;
1) If 'X' is complex, then the speed up gained by using 'int' instead of
'bool' is meaningless. E.g. it does not matter if the loop takes 10h 2s
instead of 10h 1s.
2) If 'X' is not complex, then the loop is finished in the blink of an
eye. Of course, if Y is very large, then the looping takes time and using
'int' could speed up the loop a little (lets say 5%). However, it's very
unlikely that Y will ever be large enough. Even million is a small number
for Y. We talking about hundred millions here. How often you have such a
loop in your program? Maybe if you're doing graphics, but then you
wouldn'use the object comparision in the loop. :)

I'm still not convinced that there's any way that opEquals can be made
more efficient by returning int instead of bool.

Yep. Lets consider the following simple loop, which proves the point, I
think:
for(i = 0; i < Y; i++)
X;
1) If 'X' is complex, then the speed up gained by using 'int' instead of
'bool' is meaningless. E.g. it does not matter if the loop takes 10h 2s
instead of 10h 1s.
2) If 'X' is not complex, then the loop is finished in the blink of an
eye. Of course, if Y is very large, then the looping takes time and
using 'int' could speed up the loop a little (lets say 5%). However,
it's very unlikely that Y will ever be large enough. Even million is a
small number for Y. We talking about hundred millions here. How often
you have such a loop in your program? Maybe if you're doing graphics,
but then you wouldn'use the object comparision in the loop. :)

That's an illustration of how a general expression of type int can be
more efficient than the same expression converted to a bool. But it
tells me nothing about how _opEquals_ can be more efficient if it's of
type int.
My point is this. An opEquals of type int will necessarily return 0 for
non-equal or non-0 for equal. But what can this non-0 be that can
possibly be more efficient than simply returning 1 if they're equal, and
thereby removing the need for the overhead of converting it to bool?
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.

I'm still not convinced that there's any way that opEquals can be made
more efficient by returning int instead of bool.
Stewart.

Even more so due to the SETE instruction (which gcc uses) and makes
converting to a bool after a comparison just as fast as getting an int.
I wish Walter would comment on that, because, in the point that the
discussion was left using a bool would be just as fast as an int, and I
would like a lot of those functions like opEquals to return a bool.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

I'm still not convinced that there's any way that opEquals can be made
more efficient by returning int instead of bool.
Stewart.

Even more so due to the SETE instruction (which gcc uses) and makes
converting to a bool after a comparison just as fast as getting an int.
I wish Walter would comment on that, because, in the point that the
discussion was left using a bool would be just as fast as an int, and I
would like a lot of those functions like opEquals to return a bool.

I think it was already pointed out that instruction count doesn't tell
you anything cycle counts. SETE maybe one instruction, but that doesn't
necessarily mean it's any faster. I may be. I don't know. Just it
isn't a given. Also I you're free to make your own classes return bool
from opCmp, it's just Object opCmp that returns int. And note that it's
only for _value_ comparison of objects.
Personally I think Object.opCmp returning int is an oddity, but it pales
in comparison with the mixins/imports problem, the ambiguity of auto,
and the major bugs left in variadic templates.
--bb

I'm still not convinced that there's any way that opEquals can be made
more efficient by returning int instead of bool.
Stewart.

converting to a bool after a comparison just as fast as getting an int.
I wish Walter would comment on that, because, in the point that the
discussion was left using a bool would be just as fast as an int, and I
would like a lot of those functions like opEquals to return a bool.

I think it was already pointed out that instruction count doesn't tell
you anything cycle counts. SETE maybe one instruction, but that doesn't
necessarily mean it's any faster. I may be. I don't know. Just it
isn't a given. Also I you're free to make your own classes return bool
from opCmp, it's just Object opCmp that returns int. And note that it's
only for _value_ comparison of objects.
Personally I think Object.opCmp returning int is an oddity, but it pales
in comparison with the mixins/imports problem, the ambiguity of auto,
and the major bugs left in variadic templates.
--bb

You're absolutely right. :) I think, also, that template/mixin/import
problems should be resolved as soon as possible. Then bugs (e.g. in
varidiac templates) should be fixed.
(BTW, you were referring 'opCmp' instead of 'opEquals'. And yes,
instruction count tells nothing, it's the cycle counts that, well, counts.
And I'd imagine that converting an int to bool should take relative small
amount of cycles.)

Also I you're free to make your own classes return bool
from opCmp, it's just Object opCmp that returns int.

[You mean opEquals, of course]
Maybe you forgot that a "bool opEquals" doesn't override Object.opEquals
:( .
This means that any object ever compared as [1], well, an Object will
still need to define "int opEquals" or run into a potentially
hard-to-spot bug.
[1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but
something else (such as a more derived type, typically that of your class).

Also I you're free to make your own classes return
bool from opCmp, it's just Object opCmp that returns int.

[You mean opEquals, of course]
Maybe you forgot that a "bool opEquals" doesn't override Object.opEquals
:( .
This means that any object ever compared as [1], well, an Object will
still need to define "int opEquals" or run into a potentially
hard-to-spot bug.
[1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but
something else (such as a more derived type, typically that of your class).

Yes, I thought that it was uncommon for derived classes to be concerned
with comparing against base Objects by value.
--bb

Also I you're free to make your own classes return
bool from opCmp, it's just Object opCmp that returns int.

[You mean opEquals, of course]
Maybe you forgot that a "bool opEquals" doesn't override
Object.opEquals :( .
This means that any object ever compared as [1], well, an Object will
still need to define "int opEquals" or run into a potentially
hard-to-spot bug.
[1]: or /to/, if your "bool opEquals"'s parameter isn't an Object but
something else (such as a more derived type, typically that of your
class).

Yes, I thought that it was uncommon for derived classes to be concerned
with comparing against base Objects by value.

Not for classes to be used as an AA key. From
http://www.digitalmars.com/d/arrays.html#associative :
-----
*Using Classes as the KeyType*
Classes can be used as the KeyType. For this to work, the class
definition must override the following member functions of class Object:
* hash_t toHash()
* int opEquals(Object)
* int opCmp(Object)
Note that the parameter to opCmp and opEquals is of type Object, not the
type of the class in which it is defined.
-----

Not for classes to be used as an AA key. From
http://www.digitalmars.com/d/arrays.html#associative :
-----
*Using Classes as the KeyType*
Classes can be used as the KeyType. For this to work, the class
definition must override the following member functions of class Object:
* hash_t toHash()
* int opEquals(Object)
* int opCmp(Object)
Note that the parameter to opCmp and opEquals is of type Object, not the
type of the class in which it is defined.
-----

I'm still not convinced that there's any way that opEquals can be
made more efficient by returning int instead of bool.
Stewart.

Even more so due to the SETE instruction (which gcc uses) and makes
converting to a bool after a comparison just as fast as getting an
int. I wish Walter would comment on that, because, in the point that
the discussion was left using a bool would be just as fast as an int,
and I would like a lot of those functions like opEquals to return a bool.

I think it was already pointed out that instruction count doesn't tell
you anything cycle counts. SETE maybe one instruction, but that doesn't
necessarily mean it's any faster. I may be. I don't know. Just it
isn't a given. Also I you're free to make your own classes return bool
from opCmp, it's just Object opCmp that returns int. And note that it's
only for _value_ comparison of objects.
Personally I think Object.opCmp returning int is an oddity, but it pales
in comparison with the mixins/imports problem, the ambiguity of auto,
and the major bugs left in variadic templates.
--bb