www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why does Object.opEquals return int?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Nov 08 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 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
Nov 08 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Bill Baxter wrote:
 Bill Baxter wrote:
 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.
Nov 08 2006
parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Thu, 09 Nov 2006 06:09:55 +0200, Hasan Aljudy <hasan.aljudy gmail.com=
  =

wrote:
 Bill Baxter wrote:
 Bill Baxter wrote:
 Object.opEquals returns int for some reason.  That means I can't do =



 something like:

      bool func() {
        ...
        return objA =3D=3D objB;
      }

 (Because int can't be converted to bool automatically). Instead I ha=



 to do something like

        return (objA =3D=3D objB)!=3D0;

 Which is just looks silly.

 Is there any good reason for opEquals to return an int?  opCmp has t=



 I understand, but opEquals has no business returning int.  Is this a=



 holdover from the days before bool?

 --bb



 what I actually want is:
          return objA is objB;
  So I should change my question to "Why is opEqual defined by object =


 all??"
  --bb

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

 equality.

So the original question remains: why 'opEquals' returns int?
Nov 09 2006
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html --anders
Nov 09 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Anders F Björklund wrote:
 Kristian Kilpi wrote:
 
 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html --anders

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
Nov 09 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 Anders F Björklund wrote:
 
 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html --anders

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
Nov 09 2006
prev sibling next sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Thu, 09 Nov 2006 13:57:00 +0200, Anders F Björklund <afb algonet.se>  
wrote:
 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html --anders

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.
Nov 09 2006
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
Anders F Björklund escribió:
 Kristian Kilpi wrote:
 
 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html --anders

Can't a bool be an int instead of a byte? Make it an alias of int, or something like that.
Nov 09 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
 Kristian Kilpi wrote:
 
 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of 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.
Nov 12 2006
next sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 Anders F Björklund wrote:
 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

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. :)
Nov 12 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Kristian Kilpi wrote:
 On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:

 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.
Nov 12 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Stewart Gordon wrote:
 Anders F Björklund wrote:
 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

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
Nov 13 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
Bruno Medeiros wrote:
 Stewart Gordon wrote:
 
 Anders F Björklund wrote:

 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

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
Nov 13 2006
next sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Mon, 13 Nov 2006 20:16:12 +0200, Bill Baxter <wbaxter gmail.com> wrote:

 Bruno Medeiros wrote:
 Stewart Gordon wrote:

 Anders F Björklund wrote:

 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

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.)
Nov 13 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Kristian Kilpi wrote:
 On Mon, 13 Nov 2006 20:16:12 +0200, Bill Baxter <wbaxter gmail.com> wrote:
 Personally I think Object.opCmp returning int is an oddity, but it 


 



Doh! you're right. I just finished reading the page on operator overloading[1] where Walter makes the same mistake and Stewart Gordon's correction on the associated wiki4d page[2]. So I guess opCmp was on the brain. Fix that page, Walter! [1] http://www.digitalmars.com/d/operatoroverloading.html [2] http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/OperatorOverloading --bb
Nov 13 2006
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bill Baxter wrote:
                 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).
Nov 13 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
Frits van Bommel wrote:
 Bill Baxter wrote:
 
                 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
Nov 13 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bill Baxter wrote:
 Frits van Bommel wrote:
 Bill Baxter wrote:

                 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. -----
Nov 13 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Frits van Bommel wrote:

 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.
 -----

Huh, didn't know that. Haven't done much with AA's yet. --bb
Nov 13 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 Bruno Medeiros wrote:
 Stewart Gordon wrote:

 Anders F Björklund wrote:

 Kristian Kilpi wrote:

 So the original question remains: why 'opEquals' returns int?

Walter says it is for performance reason, when e.g. sorting... http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html

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

On that previous discussion, a page which listed the internal clock counts for the instruction was linked (http://www.cs.tut.fi/~siponen/upros/intel/instr/sete_setz.html) where we can see it isn't any slower. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 18 2006