Boolean Not Equ Bit /
Posts By Walter
Difference (last change) (Author, normal page display)
Changed: 4c4
From  Post:D/314: |
|
From NG:D/314: |
Changed: 14c14
|
From Post:D/350: |
|
From NG:D/350: |
Changed: 24c24
|
From Post:D/1503: |
|
From NG:D/1503: |
Changed: 31c31
|
From Post:D/5425: |
|
From NG:D/5425: |
Changed: 41c41
|
From Post:D/5457: |
|
From NG:D/5457: |
WalterBright (the "Father of D") has made a few comments about the bit vs. bool controversy over the years. Here's some of his most interesting points...
From NG:D/314:
Sometimes there can be a penalty in the generated code, because !=0 values would have to be converted to boolean, as in:
bool b = i ? 1 : 0;There would also be confusion (I suspect) with the 'bit' type.
From NG:D/350:
I'll have to disagree that a few extra instructions are painless at 1GHz. For example, when I turn my machine on the morning, I go off and get some coffee, chat with friends, run errands, read the paper, and by the time I get back it's almost at the logon prompt <g>.
From NG:D/1503:
It's important to keep the same precedence rules as C. Nothing will screw programmers up more than to subtly shift them.
From NG:D/5425:
They're 0 and 1 of type bit.
As this thread shows, unfortunately, there simply is no right way to implement a boolean type. I remember the same discussion raging with C, with no consenus resolution.
From NG:D/5457:
One of my problems with a separate bool type is that a bool can have only two values, yet it is represented by a type that can contain many values. It just never seems to feel right.
From NG:digitalmars.D/2699:
I've followed the "what are the correct semantics of bool" debate for 15 years (it first reared its controversial head with the C standardization effort). There is no consensus, nobody agrees, and therefore no resolution.
The D options are:
- use bit which has only 'true' or 'false' values
- use int which has !0 and 0 values (the C style)
- use bool for those who don't think that bit is self-documenting <g>
From NG:digitalmars.D/2758:
Matthew wrote:
- The fact is that Walter is in an almost solitary minority on the bool issue, in terms of the opinions expressed in this forum.
BTW, both C# and Java do not allow implicit conversion of bool to int.
- Also, the bit/int opEquals() point is well made.
cmp EAX,1
sbb EAX,EAX
inc EAX
When sorting/searching a lot of data, this can add up.
- That's fair enough, it's his party after all, even though it does rankle considerably. One's choice is to stay involved, and either live with it or endeavour to change it eventually, or to find a better language. I can tell you that Walter would prefer that people with diverse opinions and experience should stay around, even if, as I'm sure we've done with "bool", it it happens to irritate the hell out of him.
- For the record, I completely disagree with Walter's apparent opinion that other, presumably more complex things, are more important. Now that doesn't mean I'm making personal attacks or anything, just that AJ's prophecy of standards committees needlessly raking over old ground is likely to come true, to all our detriments. It's a shame, because I've personally had reactions from experienced C++ (and other languages) exponents, and pretty much the first things they say are
- get rid of C's evil implicit conversions - which Walter's ruled out
Languages that don't do implicit conversions are relative failures, and I've used some of those languages and know why. They're a pain to use. They require lots of casting to get real work done, and peppering one's routine code with casts is LESS typesafe than well understood implicit type conversions. Furthermore, complex C/C++ expressions will exhibit subtle changes in behavior when converted to D. This can be a disaster if it is, for example, crypto code.
Consider, for example, the following code:
class A { void foo() { } }
void test() { A a; a.foo(); }
Which would work in C++, but fails in D. This regularly trips up people coming to D from C++. Fortunately, the code fails predictably in a manner that pinpoints the problem, the solution is explained, and one goes on. This will not happen if implicit conversion rules are changed - the program will appear to work, but the result of the expression will be subtly different. Even worse, it will compute the same result with some values of the operands, and different results with others.
So, one general principle I try to follow is that if D changes the rules, if one tries it the C++ way, one gets an obvious failure rather than a subtle, erratic one. This effectively rules out changing things like implicit conversion rules and operator precedence.
- make typedefs strong - which D has done. Hurrah!
- stop bool being an integral type - which Walter's ruled out
- make an ABI - which has so far been ignored
The ABI will happen, it's just premature.
- has it got libraries - which I would suggest more of us would be doing if there was not still such
fertile ground for language debates at a very low/fundamental level
Fundamental language debates will go on as long as there are two or more programmers <g>.
- give me decent templates - which we're certainly working towards
- So, we in our out? I'm still in.
From NG:digitalmars.D/2774:
The reason I put it in object.d is essentially to preclude confusingly conflicting versions from appearing. It's better to be consistent, perceived warts and all.
From NG:digitalmars.D/2959:
I'm bored enough with bool 10 years ago <g>.
From NG:digitalmars.D/11699:
Anders F Björklund wrote:
- I just wanted to point out that C(9X) and C++ chose one solution, and that Java and C# chose another ? D currently sides with the C side, just wanted to know if that was by choice or by accident ?
More comments from Walter