www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opEquals needs to return bool

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Because opEquals returns int, this breaks some generic code:

bool isEqual(T)(T t1, T t2)
{
    return t1 == t2;
}

class A
{
}

void main()
{
    int x1 = 5, x2 = 6;
    auto x = isEqual(x1, x2);
    auto c = isEqual("hello", "jello");

    auto a = new A;
    auto ae = isEqual(a, a); // error, cannot convert int to bool
}

Walter, you often say that some ideas can't be implemented because it would 
break generic code, what about this?

-Steve
May 15 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote

 Because opEquals returns int, this breaks some generic code:



Apparently I am not the only one who thinks so :)

http://d.puremagic.com/issues/show_bug.cgi?id=1989

Can someone please dispell this myth about performance and add it to this 
bug report?

-Steve
May 15 2008
parent reply Edward Diener <eddielee_no_spam_here tropicsoft.com> writes:
Steven Schveighoffer wrote:

 "Steven Schveighoffer" wrote

 Because opEquals returns int, this breaks some generic code:



 Apparently I am not the only one who thinks so :)
 
 http://d.puremagic.com/issues/show_bug.cgi?id=1989
 
 Can someone please dispell this myth about performance and add it to this 
 bug report?



One of the first things I mentioned on this NG when looking at D for the 
first time is to ask why opEquals returns 'int' instead of 'bool'. After 
being directed to a discussion about it and Walter's explanation of the 
reason I said that I hoped that he would come to his senses and realize 
it was just plain wrong. I have not changed my opinion one whit and I am 
glad that others also realize it is wrong. Hopefully Walter has realized 
it is wrong by this time too.

IMO, even if it were so, one does not twist programming design for a 
performance gain.
May 16 2008
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Edward Diener wrote:

 IMO, even if it were so, one does not twist programming design for
 a performance gain.



One can tweak the program, but the language should help for those 
tweaks.

-manfred
May 16 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Edward Diener (eddielee_no_spam_here tropicsoft.com)'s article

 Steven Schveighoffer wrote:

 "Steven Schveighoffer" wrote

 Because opEquals returns int, this breaks some generic code:



 Apparently I am not the only one who thinks so :)

 http://d.puremagic.com/issues/show_bug.cgi?id=1989

 Can someone please dispell this myth about performance and add it to this
 bug report?



 first time is to ask why opEquals returns 'int' instead of 'bool'. After
 being directed to a discussion about it and Walter's explanation of the
 reason I said that I hoped that he would come to his senses and realize
 it was just plain wrong. I have not changed my opinion one whit and I am
 glad that others also realize it is wrong. Hopefully Walter has realized
 it is wrong by this time too.
 IMO, even if it were so, one does not twist programming design for a
 performance gain.



For what it's worth, we tried changing this in Tango but it turns out that there
are some compiler changes needed as well.  I believe the problem we ran into
was that opEquals in structs stopped working properly, though I fail to
understand why the compiler would care about the return value of opEquals
for this feature.


Sean
May 16 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Edward Diener:

 IMO, even if it were so, one does not twist programming design for a 
 performance gain.



In some situations bools are slower, for example you can try this small program:
http://codepad.org/pD22tteK

if at line 8 you replace:
int is_valid, went_off_right_side;

With a logically more correct:
bool is_valid, went_off_right_side;

The program runs slower (with DMD on my CPU about 4% slower).

Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster.
I agree that it's better for opEquals to return a bool.
In theory the compiler may become a bit smarter and use a size_t to represent a
bool where this doesn't change the meaning of the program, but this looks not
easy in general. Another possibility is to define a second faster bool type,
but having two different bools looks bad in a language like D.

Bye,
bearophile
May 16 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Edward Diener:

 IMO, even if it were so, one does not twist programming design for a
 performance gain.



 http://codepad.org/pD22tteK
 if at line 8 you replace:
 int is_valid, went_off_right_side;
 With a logically more correct:
 bool is_valid, went_off_right_side;
 The program runs slower (with DMD on my CPU about 4% slower).



In the original discussion, it came out that DMD doesn't generate optimal
code for returning bools in this fashion, apparently because Walter was
unaware of the relevant ASM instruction to speed this up.  It's hidden
somewhere in a rather long conversation in this NG from perhaps 2 years
ago.


 Bools are bytes, while ints are 4 bytes, so sometimes ints are managed faster.



So why not just make bool a 4-byte value?  Using an integer to represent a
boolean operation is just silly.


Sean
May 16 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Sean,


 Bools are bytes, while ints are 4 bytes, so sometimes ints are
 managed faster.
 



 represent a boolean operation is just silly.
 



Or pad them to 4 bytes where you can (local variable).
May 16 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron wrote:

 On 16/05/2008, BCS <ao pathlink.com> wrote:

 Bools are bytes, while ints are 4 bytes, so sometimes ints are
 managed faster.



 represent a boolean operation is just silly.






 Honestly, I think I would be happy with a four-byte bool, in almost
 all circumstances.
 
 For those rare cases where space is an issue, there could be a second
 type, bool8, implicitly castable to and from bool, but you wouldn't
 use that by default; you'd only use it in structs where you needed to
 pack stuff tight.



Instead of having a separate type, why not just use a (u)byte in those 
cases? That's gotta be rarer than the cases where you'd want to use an 
int for a bool, so while it's the same problem, the incidence of the 
problem is reduced while not adding yet another data type that may be 
unclear for new users
May 16 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Janice Caron schrieb:


 OK, let's just keep it simple. Let bools be int-sized, and let
 opEquals return bool.



Hehe, changing the size of an existing integral type. That is going to 
be fun :)

However, i really think opEquals should be bool. int as return type is 
ugly and simply feels wrong.
May 16 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 16/05/2008, BCS <ao pathlink.com> wrote:

 Bools are bytes, while ints are 4 bytes, so sometimes ints are
 managed faster.



 represent a boolean operation is just silly.



  Or pad them to 4 bytes where you can (local variable).



Honestly, I think I would be happy with a four-byte bool, in almost
all circumstances.

For those rare cases where space is an issue, there could be a second
type, bool8, implicitly castable to and from bool, but you wouldn't
use that by default; you'd only use it in structs where you needed to
pack stuff tight.
May 16 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 16/05/2008, Robert Fraser <fraserofthenight gmail.com> wrote:

  Instead of having a separate type, why not just use a (u)byte in those
 cases? That's gotta be rarer than the cases where you'd want to use an int
 for a bool, so while it's the same problem, the incidence of the problem is
 reduced



Fair enough.

OK, let's just keep it simple. Let bools be int-sized, and let
opEquals return bool.
May 16 2008
prev sibling parent Georg Wrede <georg nospam.org> writes:
bearophile wrote:

 Edward Diener:
 

 IMO, even if it were so, one does not twist programming design for 
 a performance gain.



 In some situations bools are slower, for example you can try this 
 small program: http://codepad.org/pD22tteK
 
 if at line 8 you replace: int is_valid, went_off_right_side;
 
 With a logically more correct: bool is_valid, went_off_right_side;
 
 The program runs slower (with DMD on my CPU about 4% slower).
 
 Bools are bytes, while ints are 4 bytes, so sometimes ints are 
 managed faster. I agree that it's better for opEquals to return a 
 bool. In theory the compiler may become a bit smarter and use a 
 size_t to represent a bool where this doesn't change the meaning of 
 the program, but this looks not easy in general. Another possibility 
 is to define a second faster bool type, but having two different 
 bools looks bad in a language like D.



I think bools should be of the fastest type available on the machine. On
x86 that is int. Bytes may spare you some room (only in some special
cases, I might add!!), but they really are slower.

This slowness results from the processor not being able to load and
store bytes as efficiently as ints. A byte store, for example, requires
a load of the other 3 bytes (because addresses are accessable only 4
bytes at a time on current 32 bit processors), then a computation of a
mask, the an and operation, then an alignment operation of the value
we're storing, then oring it with the mask result, and then storing the
4 bytes into memory. (Of course, this is what conceptually happens, and
some of the parts are sort-of optimized away in the pipeline or with
special datalines in the CPU. But still, this is essentially what has to
happen when storing a byte.)

With a language having the Hello World in the hundreds of kilobytes, and
only usable outside of x86 Windows/Linux by happenstance, I
find it peculiar if anybody could even imagine an excuse for having
bool be anything else than int size.

---

The above is an issue separate from that of storage. A programmer may
want to use packed bytes to store boolean values in structs, or even bit
arrays. But that is, and should remain his choice.

---

 From previous experience (the Bit Datatype days), I wouldn't bet on this
changing too soon. But I sincerely hope I'm wrong this time.
May 16 2008