digitalmars.D - opEquals needs to return bool
- Steven Schveighoffer (19/19) May 15 2008 Because opEquals returns int, this breaks some generic code:
- Steven Schveighoffer (6/7) May 15 2008 Apparently I am not the only one who thinks so :)
- Edward Diener (10/19) May 16 2008 One of the first things I mentioned on this NG when looking at D for the...
- Manfred Nowak (4/6) May 16 2008 One can tweak the program, but the language should help for those
- Sean Kelly (7/26) May 16 2008 For what it's worth, we tried changing this in Tango but it turns out th...
- bearophile (13/15) May 16 2008 In some situations bools are slower, for example you can try this small ...
- Sean Kelly (9/20) May 16 2008 In the original discussion, it came out that DMD doesn't generate optima...
- BCS (2/8) May 16 2008 Or pad them to 4 bytes where you can (local variable).
- Janice Caron (7/13) May 16 2008 Honestly, I think I would be happy with a four-byte bool, in almost
- Robert Fraser (6/21) May 16 2008 Instead of having a separate type, why not just use a (u)byte in those
- Janice Caron (4/8) May 16 2008 Fair enough.
- Frank Benoit (5/7) May 16 2008 Hehe, changing the size of an existing integral type. That is going to
- Georg Wrede (25/46) May 16 2008 I think bools should be of the fastest type available on the machine. On
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
"Steven Schveighoffer" wroteBecause 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
Steven Schveighoffer wrote:"Steven Schveighoffer" wroteOne 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.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?
May 16 2008
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
== Quote from Edward Diener (eddielee_no_spam_here tropicsoft.com)'s articleSteven Schveighoffer wrote: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"Steven Schveighoffer" wroteOne 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.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?
May 16 2008
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
== Quote from bearophile (bearophileHUGS lycos.com)'s articleEdward Diener: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.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.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
Reply to Sean,Or pad them to 4 bytes where you can (local variable).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.
May 16 2008
On 16/05/2008, BCS <ao pathlink.com> wrote: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.Or pad them to 4 bytes where you can (local variable).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.
May 16 2008
Janice Caron wrote:On 16/05/2008, BCS <ao pathlink.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 while not adding yet another data type that may be unclear for new usersHonestly, 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.Or pad them to 4 bytes where you can (local variable).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.
May 16 2008
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 reducedFair enough. OK, let's just keep it simple. Let bools be int-sized, and let opEquals return bool.
May 16 2008
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
bearophile wrote:Edward Diener: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.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.
May 16 2008