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

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

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.

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

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

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

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

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

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.

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.

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.