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