digitalmars.D - Why does Object.opEquals return int?
- Bill Baxter (14/14) Nov 08 2006 Object.opEquals returns int for some reason. That means I can't do
- Bill Baxter (7/27) Nov 08 2006 After seeing some crashes upon comparing with null objects, I realized
- Hasan Aljudy (3/34) Nov 08 2006 The "is" operator just compares for references/pointers, not object
- Kristian Kilpi (9/40) Nov 09 2006 =
- =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= (4/5) Nov 09 2006 Walter says it is for performance reason, when e.g. sorting...
- Bill Baxter (6/16) Nov 09 2006 Thanks for the link. Not sure how it matters when sorting, because then...
- Chris Nicholson-Sauls (7/28) Nov 09 2006 The main use seems to be for AA's, along with toHash(). At least that's...
- Kristian Kilpi (14/19) Nov 09 2006 Well, I don't like it ;) , even though more speed is good. 'opEquals' ha...
- Ary Manzana (3/12) Nov 09 2006 Can't a bool be an int instead of a byte? Make it an alias of int, or
- Stewart Gordon (12/19) Nov 12 2006 I'm still not convinced that there's any way that opEquals can be made
- Kristian Kilpi (16/25) Nov 12 2006 Yep. Lets consider the following simple loop, which proves the point, I ...
-
Stewart Gordon
(20/41)
Nov 12 2006
- Bruno Medeiros (9/23) Nov 13 2006 Even more so due to the SETE instruction (which gcc uses) and makes
- Bill Baxter (11/36) Nov 13 2006 I think it was already pointed out that instruction count doesn't tell
- Kristian Kilpi (8/43) Nov 13 2006 You're absolutely right. :) I think, also, that template/mixin/import
- Bill Baxter (9/14) Nov 13 2006 Doh! you're right. I just finished reading the page on operator
- Frits van Bommel (9/11) Nov 13 2006 [You mean opEquals, of course]
- Bill Baxter (4/21) Nov 13 2006 Yes, I thought that it was uncommon for derived classes to be concerned
- Frits van Bommel (13/35) Nov 13 2006 Not for classes to be used as an AA key. From
- Bill Baxter (3/18) Nov 13 2006 Huh, didn't know that. Haven't done much with AA's yet.
- Bruno Medeiros (8/47) Nov 18 2006 On that previous discussion, a page which listed the internal clock
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
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? --bbAfter 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
Bill Baxter wrote:Bill Baxter wrote:The "is" operator just compares for references/pointers, not object equality.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? --bbAfter 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
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 =ve =something like: bool func() { ... return objA =3D=3D objB; } (Because int can't be converted to bool automatically). Instead I ha=o, =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=ed =holdover from the days before bool? --bbAfter seeing some crashes upon comparing with null objects, I realiz=at =what I actually want is: return objA is objB; So I should change my question to "Why is opEqual defined by object =all??" --bbThe "is" operator just compares for references/pointers, not object =equality.So the original question remains: why 'opEquals' returns int?
Nov 09 2006
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
Anders F Björklund wrote:Kristian Kilpi wrote: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. --bbSo 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
Bill Baxter wrote:Anders F Björklund wrote: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-SaulsKristian Kilpi wrote: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. --bbSo 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
On Thu, 09 Nov 2006 13:57:00 +0200, Anders F Björklund <afb algonet.se> wrote:Kristian Kilpi wrote: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.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
Anders F Björklund escribió:Kristian Kilpi wrote:Can't a bool be an int instead of a byte? Make it an alias of int, or something like that.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
Anders F Björklund wrote:Kristian Kilpi wrote: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.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
Nov 12 2006
On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998 yahoo.com> wrote:Anders F Björklund wrote: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. :)Kristian Kilpi wrote:I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool. Stewart.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
Nov 12 2006
Kristian Kilpi wrote:On Sun, 12 Nov 2006 15:14:01 +0200, Stewart Gordon <smjg_1998 yahoo.com> wrote:<snip><snip>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
Stewart Gordon wrote:Anders F Björklund wrote: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#DKristian Kilpi wrote:I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool. Stewart.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
Nov 13 2006
Bruno Medeiros wrote:Stewart Gordon wrote: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. --bbAnders F Björklund wrote: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.Kristian Kilpi wrote:I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool. Stewart.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
Nov 13 2006
On Mon, 13 Nov 2006 20:16:12 +0200, Bill Baxter <wbaxter gmail.com> wrote:Bruno Medeiros wrote: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.)Stewart Gordon wrote: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. --bbAnders F Björklund wrote: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.Kristian Kilpi wrote:I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool. Stewart.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
Nov 13 2006
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 itDoh! 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(BTW, you were referring 'opCmp' instead of 'opEquals'. And yes,
Nov 13 2006
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
Frits van Bommel wrote:Bill Baxter wrote:Yes, I thought that it was uncommon for derived classes to be concerned with comparing against base Objects by value. --bbAlso 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
Bill Baxter wrote: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. -----Bill Baxter wrote:Yes, I thought that it was uncommon for derived classes to be concerned with comparing against base Objects by value.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
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
Bill Baxter wrote:Bruno Medeiros wrote: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#DStewart Gordon wrote: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. --bbAnders F Björklund wrote: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.Kristian Kilpi wrote:I'm still not convinced that there's any way that opEquals can be made more efficient by returning int instead of bool. Stewart.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
Nov 18 2006