www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - bool

reply Arcane Jill <Arcane_member pathlink.com> writes:
I've just noticed that the keyword "bool" is accepted by the compiler. Turns out
this is because it's defined in "object.d" as an alias for bit.

At the very least, this enables us to document our code, by having appropriate
functions return bool instead of bit.

Walter, pending the implementation of a real non-arithmetic bool type, is there
any chance you could change this alias from bit to int? Then at least opEquals()
could return a bool. (Or better still, have opEquals() return bool).

Arcane Jill
Jun 01 2004
next sibling parent Daniel Horn <hellcatv hotmail.com> writes:
agree...unless you're passing bools in bit vectors (in which case you'd 
probably want to document it as such esp with these bit-slicing quirks) 
the bool should be an int or at worst a byte on reasonably modern platforms.

Arcane Jill wrote:

 I've just noticed that the keyword "bool" is accepted by the compiler. Turns
out
 this is because it's defined in "object.d" as an alias for bit.
 
 At the very least, this enables us to document our code, by having appropriate
 functions return bool instead of bit.
 
 Walter, pending the implementation of a real non-arithmetic bool type, is there
 any chance you could change this alias from bit to int? Then at least
opEquals()
 could return a bool. (Or better still, have opEquals() return bool).
 
 Arcane Jill
 
 

Jun 01 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9itp0$2dpn$1 digitaldaemon.com...
 I've just noticed that the keyword "bool" is accepted by the compiler.

 this is because it's defined in "object.d" as an alias for bit.

 At the very least, this enables us to document our code, by having

 functions return bool instead of bit.

 Walter, pending the implementation of a real non-arithmetic bool type, is

 any chance you could change this alias from bit to int? Then at least

 could return a bool. (Or better still, have opEquals() return bool).

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: 1) use bit which has only 'true' or 'false' values 2) use int which has !0 and 0 values (the C style) 3) use bool for those who don't think that bit is self-documenting <g> and it's going to stay that way. There's a lot of very cool stuff coming for D, and I can't wait to get it implemented. I've had as much as I can take on the whole 15 years of bool business, I've got the scars to prove it <g>.
Jun 01 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Hear, hear. Where bool is concerned, it's more constructive to just move on
...


"Walter" <newshound digitalmars.com> wrote in message
news:c9j8jo$2t58$1 digitaldaemon.com...
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:c9itp0$2dpn$1 digitaldaemon.com...
 I've just noticed that the keyword "bool" is accepted by the compiler.

 this is because it's defined in "object.d" as an alias for bit.

 At the very least, this enables us to document our code, by having

 functions return bool instead of bit.

 Walter, pending the implementation of a real non-arithmetic bool type,


 there
 any chance you could change this alias from bit to int? Then at least

 could return a bool. (Or better still, have opEquals() return bool).

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

 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

 and it's going to stay that way. There's a lot of very cool stuff coming

 D, and I can't wait to get it implemented. I've had as much as I can take

 the whole 15 years of bool business, I've got the scars to prove it <g>.

Jun 01 2004
prev sibling next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
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:

1) use bit which has only 'true' or 'false' values
2) use int which has !0 and 0 values (the C style)
3) use bool for those who don't think that bit is self-documenting <g>

and it's going to stay that way. There's a lot of very cool stuff coming for
D, and I can't wait to get it implemented. I've had as much as I can take on
the whole 15 years of bool business, I've got the scars to prove it <g>.

opEquals() should return bool. Pure and simple. There is *NO* disagreement on this. Apart from yours, anyway. I don't care what bool is aliased to. But whatever it is, opEquals should return it. The current situation where opEquals returns int, but bool is aliased to bit, is just silly. Overrides of opEquals are (currently) not allowed to return bool, and that just sucks. Particularly when both parts of this inconsistency originate from the same file (object.d). Jill
Jun 02 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter. There have been many different suggestions regarding *implementation* - and if you want to call that "no consensus" then that's your viewpoint - but regarding the principle that a bool is not arithmetic, if you have been following this forum, you'll know you are in a very small minority here. If we have to wait until someone implements the SECOND D-compiler before we see a bool type, then so be it. But I'll bet you any amount of money you like it will be in the ISO/ANSI standard which eventually supercedes the original implementation. I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the face. Unless you are defining "consensus" as "unanimous opinion" - in which case your comment "and therefore no resolution" is absurd. Arcane Jill
Jun 02 2004
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Dude ... I sincerely hope you're just venting. You do make a valid point
about opEquals() in your prior post but I doubt this, whatever it is, helps
your cause in the slightest.

My 2 pence worth.

BTW: according to your 'handle', you appear to claim some heritage to the
proverbial "Arc Angel". If so, perhaps you might consider setting a higher
standard? These personal attacks are just so boring ...


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9k035$v8g$1 digitaldaemon.com...
 In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter. There have been many different suggestions regarding *implementation* -

 you want to call that "no consensus" then that's your viewpoint - but

 the principle that a bool is not arithmetic, if you have been following

 forum, you'll know you are in a very small minority here.

 If we have to wait until someone implements the SECOND D-compiler before

 a bool type, then so be it. But I'll bet you any amount of money you like

 will be in the ISO/ANSI standard which eventually supercedes the original
 implementation.

 I think it's a shame that you don't like the bool type, but I think it's a
 bigger shame that you don't see a consensus when it's staring you in the

 Unless you are defining "consensus" as "unanimous opinion" - in which case

 comment "and therefore no resolution" is absurd.

 Arcane Jill

Jun 02 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Now I'm known to have a big mouth and thick skin, but even trying out a
permeable
skin for a moment I fail to see where Arcane Jill has resorted to any low
tactics.

The fact is that Walter is in an almost solitary minority on the bool issue, in
terms of the opinions expressed in this forum. Also, the bit/int opEquals()
point
is well made.

Now, Walter's been umoveable for as long as I can remember on this issue, and
while I still hope that he will see the (or, at least, our) light, I don't think
that's the case.

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
    - 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
    - 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
    - give me decent templates - which we're certainly working towards

So, we in our out? I'm still in. ;)



"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:c9k3ah$13fo$1 digitaldaemon.com...
 Dude ... I sincerely hope you're just venting. You do make a valid point
 about opEquals() in your prior post but I doubt this, whatever it is, helps
 your cause in the slightest.

 My 2 pence worth.

 BTW: according to your 'handle', you appear to claim some heritage to the
 proverbial "Arc Angel". If so, perhaps you might consider setting a higher
 standard? These personal attacks are just so boring ...


 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:c9k035$v8g$1 digitaldaemon.com...
 In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter. There have been many different suggestions regarding *implementation* -

 you want to call that "no consensus" then that's your viewpoint - but

 the principle that a bool is not arithmetic, if you have been following

 forum, you'll know you are in a very small minority here.

 If we have to wait until someone implements the SECOND D-compiler before

 a bool type, then so be it. But I'll bet you any amount of money you like

 will be in the ISO/ANSI standard which eventually supercedes the original
 implementation.

 I think it's a shame that you don't like the bool type, but I think it's a
 bigger shame that you don't see a consensus when it's staring you in the

 Unless you are defining "consensus" as "unanimous opinion" - in which case

 comment "and therefore no resolution" is absurd.

 Arcane Jill


Jun 02 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:
<snip>

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
  

Ok I know int <-> char conversions still are possible in D but give Walter some credit he did remove a lot of the implicit conversions such as float<->int a few months back. -- -Anderson: http://badmama.com.au/~anderson/
Jun 02 2004
parent "Walter" <newshound digitalmars.com> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c9ks17$26t9$1 digitaldaemon.com...
 Matthew wrote:
It's a shame, because I've personally had reactions from experienced
C++ (and other languages) exponents, and pretty much the first things


are
    - get rid of C's evil implicit conversions - which Walter's ruled out

Walter some credit he did remove a lot of the implicit conversions such as float<->int a few months back.

int still converts to float, just not the other way. I actually had disabled implicit integral narrowing conversions at one point, but the compiler became a nagging ninny nuisance and was more annoying than useful. It's interesting how *accustomed* I am to C's expression rules, and I suspect it would be the same with other longtime C/C++ programmers.
Jun 02 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c9k5lf$16nj$1 digitaldaemon.com...
 The fact is that Walter is in an almost solitary minority on the bool

 terms of the opinions expressed in this forum.

The debate on bool goes back long, long before D. If there was consensus on what it should do, it would have been designed that way in C and C++, both languages more or less independently came up with a bool type, there were no legacy backwards compatibility issues, and in both languages bool implicitly converts to integral types. C and C++ doing it one way does not dictate what D does, but since D is meant to appeal to C/C++ programmers, diverging from C/C++ semantics has to have a pretty strong case for it. BTW, both C# and Java do not allow implicit conversion of bool to int.
 Also, the bit/int opEquals() point is well made.

The reason for it being the int 0/!0 is because converting it to 0/1 adds 3 instructions: 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

 that Walter would prefer that people with diverse opinions and experience

 stay around, even if, as I'm sure we've done with "bool", it it happens to
 irritate the hell out of him.

No, it doesn't irritate the hell out of me <g>. I'm in the wrong business if it did. It does seem to irritate others, though, and I don't really understand why.
 For the record, I completely disagree with Walter's apparent opinion that

 presumably more complex things, are more important. Now that doesn't mean

 making personal attacks or anything, just that AJ's prophecy of standards
 committees needlessly raking over old ground is likely to come true, to

 detriments. It's a shame, because I've personally had reactions from

 C++ (and other languages) exponents, and pretty much the first things they

 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

 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. ;)

And I'm glad you are, and hope Arcane Jill will stick around, too.
Jun 02 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
    - make an ABI - which has so far been ignored

The ABI will happen, it's just premature.

You can't imagine how glad I am to hear that. The missing C++ ABI has been a huge iron anchor that held the language back. I also think it is one of the primary reasons why most libraries are still written in C instead of C++. Hauke
Jun 02 2004
parent "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9l432$2in3$1 digitaldaemon.com...
 Walter wrote:
    - make an ABI - which has so far been ignored

The ABI will happen, it's just premature.

You can't imagine how glad I am to hear that. The missing C++ ABI has been a huge iron anchor that held the language back. I also think it is one of the primary reasons why most libraries are still written in C instead of C++.

I think the right time to write it is when 1.0 is released, and it will be just a document of "how it works".
Jun 02 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9l2q1$2gui$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c9k5lf$16nj$1 digitaldaemon.com...
 The fact is that Walter is in an almost solitary minority on the bool

 terms of the opinions expressed in this forum.

The debate on bool goes back long, long before D. If there was consensus on what it should do, it would have been designed that way in C and C++, both languages more or less independently came up with a bool type, there were no legacy backwards compatibility issues, and in both languages bool implicitly converts to integral types. C and C++ doing it one way does not dictate what D does, but since D is meant to appeal to C/C++ programmers, diverging from C/C++ semantics has to have a pretty strong case for it. BTW, both C# and Java do not allow implicit conversion of bool to int.

As you well know, from reviewing "Imperfect C++", I think C/C++ have made a grave mistake by not prescribing that sizeof(bool) == sizeof(int), and why compiler manufacturers have "utilised" that missing prescription to blunder and defined sizeof(bool) == 1. I don't advocate that D do either of these things - i.e. fail to prescribe the size and presribe/use it as 1 - but D actually goes even further from the poor situation with sizeof(bool), since it defines it as a bit. This merely compounds the problems of having it as == 1, and adds the new hassles of addressing elements in arrays of "bool"s.
 Also, the bit/int opEquals() point is well made.

The reason for it being the int 0/!0 is because converting it to 0/1 adds 3 instructions: cmp EAX,1 sbb EAX,EAX inc EAX When sorting/searching a lot of data, this can add up.

Isn't this a clear argument for why we should prefer int to bit, and, therefore, why the bool alias should be int? If not, then I'm totally lost on your point.
 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

 that Walter would prefer that people with diverse opinions and experience

 stay around, even if, as I'm sure we've done with "bool", it it happens to
 irritate the hell out of him.

No, it doesn't irritate the hell out of me <g>. I'm in the wrong business if it did. It does seem to irritate others, though, and I don't really understand why.

Well, I know you're skin's even thicker than mine, but you clearly _seem_ at a point of some exasperation to state that "and it's going to stay that way. There's a lot of very cool stuff coming for D, and I can't wait to get it implemented. I've had as much as I can take on the whole 15 years of bool business". That reads to me like "I'm sick of this debate. I'm not changing my mind. You should all (let me) get on with more important things."
 For the record, I completely disagree with Walter's apparent opinion that

 presumably more complex things, are more important. Now that doesn't mean

 making personal attacks or anything, just that AJ's prophecy of standards
 committees needlessly raking over old ground is likely to come true, to

 detriments. It's a shame, because I've personally had reactions from

 C++ (and other languages) exponents, and pretty much the first things they

 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.

I can see some sense in that, but I remain skeptical. If conditional (sub-)expressions are boolean, and not convertible to int Now here's an idea. We (almost) all agree that we don't want pragmas, warnings or compiler-options that basically change the definition of the language. However, since we're in the pre-1.0 stage, why not allow a compiler flag -strict_boolean that will switch on a boolean type, sub-expressions and switch off interconversions. Then we can test, rather than debate, just how beneficial/onerous this stuff would be. Yes, this more work, but the advantages would be: 1. It would kill this argument forever 2. It would make a great article 3. It would make a great chapter when we write "The Design and Evolution of D". 4. We could use this uncontestable knowledge in the many language-bashing/lauding wars that are to come.
 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

Not based on any of the changes I'd want. The compiler would simply fail to compile on the formerly-convertible expression. Nothing subtle about that.
- 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.

Understood. I didn't mean to imply that it's not going to happen, just that it's not done so yet.
     - has it got libraries - which I would suggest more of us would be

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

True. And in the spirit of that, I will formally state that, despite my disagreeing with it, I can live with the implicit conversions between bool and int. What I cannot live with, and won't program to, is the fact that the boolean type (or alias) bool is a bit. This means that in all my D coding I'm going to have to continue to define the "boolean" type, based on int, albeit that I will move (and have already in the recent upgrade of recls) from it being a typedef to being an alias. Can you meet me (/ us) halfway, and at least change the standard alias of bool from bit to int, and I can jettison all my "boolean"-based code?
     - give me decent templates - which we're certainly working towards

 So, we in our out? I'm still in. ;)

And I'm glad you are, and hope Arcane Jill will stick around, too.

Limpet-like. :-)
Jun 02 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew wrote:
Fundamental language debates will go on as long as there are two or more
programmers <g>.

True. And in the spirit of that, I will formally state that, despite my disagreeing with it, I can live with the implicit conversions between bool and int. What I cannot live with, and won't program to, is the fact that the boolean type (or alias) bool is a bit. This means that in all my D coding I'm going to have to continue to define the "boolean" type, based on int, albeit that I will move (and have already in the recent upgrade of recls) from it being a typedef to being an alias. Can you meet me (/ us) halfway, and at least change the standard alias of bool from bit to int, and I can jettison all my "boolean"-based code?

I agree with Matthew that bool should be an int. But, there is one thing that should be considered. If true is defined as !=0 instead of 1 then the following code will not work as intuitively expected: bool a=1; //true bool b=2; //also true if(a && b!=a) printf("b=false"); //wrong answer I think we could definitely put this to rest if bool was an int with one modification: a==b should be rewritten as (a && b) || (!a && !b). Yes, it would cost performance but only when two bools are compared. And this happens VERY rarely (at least in my code). Plus an advanced compiler probably could optimize this back down to a single compare in a local context where it knows that true will always be 1. When a bool is a bit, on the other hand, bool arrays will be slow and (more importantly) not easily slicable. And bool arrays are not quite that rare. Hauke
Jun 02 2004
parent Derek Parnell <derek psych.ward> writes:
On Thu, 03 Jun 2004 01:47:36 +0200, Hauke Duden wrote:

 Matthew wrote:
Fundamental language debates will go on as long as there are two or more
programmers <g>.

True. And in the spirit of that, I will formally state that, despite my disagreeing with it, I can live with the implicit conversions between bool and int. What I cannot live with, and won't program to, is the fact that the boolean type (or alias) bool is a bit. This means that in all my D coding I'm going to have to continue to define the "boolean" type, based on int, albeit that I will move (and have already in the recent upgrade of recls) from it being a typedef to being an alias. Can you meet me (/ us) halfway, and at least change the standard alias of bool from bit to int, and I can jettison all my "boolean"-based code?

I agree with Matthew that bool should be an int. But, there is one thing that should be considered. If true is defined as !=0 instead of 1 then the following code will not work as intuitively expected: bool a=1; //true bool b=2; //also true if(a && b!=a) printf("b=false"); //wrong answer

I'm now sure I didn't have enough sleep last night ;-) I thought that because 'a' and 'b' are declared as bool that the above statement is interpreted by D as ... bool a=1; //true bool b=2; //also true if( (a!=0) && ((b!=0)!=(a!=0))) printf("b=false"); //wrong answer
 I think we could definitely put this to rest if bool was an int with one 
 modification: a==b should be rewritten as (a && b) || (!a && !b).

And thus 'a==b' is really '(a!=0)==(b!=0)'
 Yes, it would cost performance but only when two bools are compared. And 
 this happens VERY rarely (at least in my code). Plus an advanced 
 compiler probably could optimize this back down to a single compare in a 
 local context where it knows that true will always be 1.
 
 When a bool is a bit, on the other hand, bool arrays will be slow and 
 (more importantly) not easily slicable. And bool arrays are not quite 
 that rare.

Agreed. Arrays of bools are definitely used. -- Derek 3/Jun/04 11:46:11 AM
Jun 02 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c9ln6r$du0$1 digitaldaemon.com...
 As you well know, from reviewing "Imperfect C++", I think C/C++ have made

 mistake by not prescribing that sizeof(bool) == sizeof(int), and why

 manufacturers have "utilised" that missing prescription to blunder and

 sizeof(bool) == 1.

Your argument that sizeof(bool) should be fixed and not left up to the implementation is sound, and is done in D. Your other argument that bool should be the same size as int for efficiency reasons isn't as compelling. To convert an into a bool requires something equivalent to (i?1:0), regardless of the size of the bool. Having random bool variables be int sized is no problem, but having arrays of them is a problem.
 I don't advocate that D do either of these things - i.e. fail to prescribe

 size and presribe/use it as 1 - but D actually goes even further from the

 situation with sizeof(bool), since it defines it as a bit. This merely

 the problems of having it as == 1, and adds the new hassles of addressing
 elements in arrays of "bool"s.

A 'bit' by itself has a size of 1 byte. Only when turned into an array are they packed into bit positions in memory. While this doesn't address the bit array slicing problem, it seems to work rather well otherwise.
 Also, the bit/int opEquals() point is well made.



 instructions:
     cmp    EAX,1
     sbb    EAX,EAX
     inc    EAX
 When sorting/searching a lot of data, this can add up.


 why the bool alias should be int?

No, because even if it is an int it still has to go through the (i?1:0) operation.
 Well, I know you're skin's even thicker than mine, but you clearly _seem_

 point of some exasperation to state that "and it's going to stay that way.
 There's a lot of very cool stuff coming for D, and I can't wait to get it
 implemented. I've had as much as I can take on the whole 15 years of bool
 business".
 That reads to me like "I'm sick of this debate. I'm not changing my mind.

 should all (let me) get on with more important things."

Ok, I can see how you read it that way. But I just wanted to point out that, while it's fun debating these things, it's time for D to move on.
 If conditional
 (sub-)expressions are boolean, and not convertible to int

What's the problem with converting them to int? Why pretend it isn't what it is, a 1 or a 0? I've built TTL hardware, single board computers from scratch, etc., and 0/1, true/false, on/off, yes/no, +5V/0V are all the same in my mind. (In fact, the only reason true and false are keywords in D is not because they are that useful, but because so many programmers believe they are useful <g> and would otherwise produce multiple conflicting definitions of them. It's also there to drive a stake in the heart of the execrable BASIC convention that true is 0xFFFF, and to thwart the equally miserable attempts to make tristate or even quadstate 'bools'.)
 Now here's an idea. We (almost) all agree that we don't want pragmas,

 compiler-options that basically change the definition of the language.

 since we're in the pre-1.0 stage, why not allow a compiler

 that will switch on a boolean type, sub-expressions and switch off
 interconversions. Then we can test, rather than debate, just how
 beneficial/onerous this stuff would be.

Having an alias of bool to int will mean that one could, for example, store '3' in a so-called bool. This is just no good. A bool needs to be constrained to be 0 or 1, or it isn't a bool. The D 'bit' type enforces this constraint, and so is the bool candidate. The basic problem is there are tradeoffs with the semantics of bool and its implementation. Any time there are tradeoffs, there will be controversy. There is no design for it that will put things to rest once and for all.
 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


 that pinpoints the problem, the solution is explained, and one goes on.


 will not happen if implicit conversion rules are changed

Not based on any of the changes I'd want. The compiler would simply fail

 compile on the formerly-convertible expression. Nothing subtle about that.

That's true for implicit narrowing conversions.
 The ABI will happen, it's just premature.


 not done so yet.

It's actually quite a bit of work to write.
 True. And in the spirit of that, I will formally state that, despite my
 disagreeing with it, I can live with the implicit conversions between bool

 int. What I cannot live with, and won't program to, is the fact that the

 type (or alias) bool is a bit. This means that in all my D coding I'm

 have to continue to define the "boolean" type, based on int, albeit that I

 move (and have already in the recent upgrade of recls) from it being a

 being an alias.

All right.
 Can you meet me (/ us) halfway, and at least change the standard alias of

 from bit to int, and I can jettison all my "boolean"-based code?

Ack <g>
Jun 02 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9lrlu$k74$1 digitaldaemon.com>, Walter says...

A 'bit' by itself has a size of 1 byte. Only when turned into an array are
they packed into bit positions in memory.

Can I just add at this point that in all my life, I have never seen an array of boolean truth values. An array of bits, yes, but an array of bools? I'm not suggesting that such an animal is fantasy, but it's rare enough to be considered an endangered species <g>. I don't think the language need worry about this. If some programmer wants to bit-pack bools then they can always cast them to bits first. Jill PS. I've given up debating about whether or not there should be a separate bool type, and simply written one. My only remaining concern now is the opEquals() should return a bool - regardless of what bool is aliased to.
Jun 02 2004
next sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:

 Can I just add at this point that in all my life, I have never seen an
 array of boolean truth values.

This can also be interpreted as another indicator that the semantic distinction between bit and bool is rather blurred. Where is the semantic difference between a bitmask and an array of boolean values? Of course, there are many clear cases, where you can clearly say "This is a bool" or "This has to be a bit" - but there also is a huge grey area. Especially when working with array expressions (vectorized), it is very often extremely common to do arithmetics that interpret a bool field as a field with the values 0 or 1. On modern, pipelining processors, in many cases, it even is more efficient to have a floating point multiplication with either 0.0 or 1.0 than doing conditional statements since the latter may break the pipeline. Of course, an intelligent compiler might do something like this as optimization, but for that to work, D would probably have to be tailored a lot more towards vectorized expressions (i.e. array expressions)
Jun 03 2004
prev sibling parent reply "KTC" <me here.com> writes:
"Arcane Jill" wrote...
 Can I just add at this point that in all my life, I have never seen an

 boolean truth values.

Whereas I actually see it all the time. Of course, it could just be my university lecuters and their examples.... -- Experience is a good school but the fees are high. - Heinrich Heine
Jun 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I'm with AJ. I've never seen anyone use a data structure where the compression
of
boolean types into a bit field structure was mandated by size concerns.
(Naturally I've seen code where things are mapped to bit fields to working with
network protocols. But such things are specialised, and in any case I've never
seen/heard of someone using something like a vector<bool> to map to a network
packet.)

Again, I'd be interested to hear of some real examples.

The ears are open ...



"KTC" <me here.com> wrote in message news:c9mu1m$26d3$1 digitaldaemon.com...
 "Arcane Jill" wrote...
 Can I just add at this point that in all my life, I have never seen an

 boolean truth values.

Whereas I actually see it all the time. Of course, it could just be my university lecuters and their examples.... -- Experience is a good school but the fees are high. - Heinrich Heine

Jun 03 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

I'm with AJ. I've never seen anyone use a data structure where the compression
of
boolean types into a bit field structure was mandated by size concerns.
  

(Naturally I've seen code where things are mapped to bit fields to working with
network protocols. But such things are specialised, and in any case I've never
seen/heard of someone using something like a vector<bool> to map to a network
packet.)

Again, I'd be interested to hear of some real examples.

The ears are open ...
  

I've used bit fields for PVS (potentially visible sets) in hidden surface removal (HSR). Then you need to use ZRLE as well so you can't use D's bit arrays anyway. The amount of potential visible sets in a HSR program tends to be around n^2 where n is the number of polygons, which can be a hell of a lot of memory, particularly if not compressed. I'm sure there are heaps of circumstances where bit arrays are very useful for keeping size down while keeping the program readable. Often its more efficient to use a bit array then a bool array as then the cache doesn't thrash so much. Particularly for things that need to be accessed in sequence. -- -Anderson: http://badmama.com.au/~anderson/
Jun 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Well, as you say, that's a bit array, rather than a bool array. However, in the
context you describe one would be hard pressed to come up with a difference
between a boolean and a bit.

Such examples can be seized on by either side, I suppose. To me it seems to
indicate that an array of bool is still a fatuous thing, because I see what
you're talking about as an array of bits. But I guess I could equally see that
it's a boolean array, and that therefore bool must be a bit.

Ho hum. I sorely tire of this. :(


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c9n7l9$2jq8$1 digitaldaemon.com...
 Matthew wrote:

I'm with AJ. I've never seen anyone use a data structure where the compression


boolean types into a bit field structure was mandated by size concerns.


(Naturally I've seen code where things are mapped to bit fields to working


network protocols. But such things are specialised, and in any case I've never
seen/heard of someone using something like a vector<bool> to map to a network
packet.)

Again, I'd be interested to hear of some real examples.

The ears are open ...

I've used bit fields for PVS (potentially visible sets) in hidden surface removal (HSR). Then you need to use ZRLE as well so you can't use D's bit arrays anyway. The amount of potential visible sets in a HSR program tends to be around n^2 where n is the number of polygons, which can be a hell of a lot of memory, particularly if not compressed. I'm sure there are heaps of circumstances where bit arrays are very useful for keeping size down while keeping the program readable. Often its more efficient to use a bit array then a bool array as then the cache doesn't thrash so much. Particularly for things that need to be accessed in sequence. -- -Anderson: http://badmama.com.au/~anderson/

Jun 03 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

fatuous 
  

I feel fatuous. -- -Anderson: http://badmama.com.au/~anderson/
Jun 03 2004
prev sibling next sibling parent "KTC" <me here.com> writes:
"Walter" wrote...
 What's the problem with converting them to int? Why pretend it isn't what

 is, a 1 or a 0? I've built TTL hardware, single board computers from
 scratch, etc., and 0/1, true/false, on/off, yes/no, +5V/0V are all the

 in my mind. (In fact, the only reason true and false are keywords in D is
 not because they are that useful, but because so many programmers believe
 they are useful <g> and would otherwise produce multiple conflicting
 definitions of them. It's also there to drive a stake in the heart of the
 execrable BASIC convention that true is 0xFFFF, and to thwart the equally
 miserable attempts to make tristate or even quadstate 'bools'.)

Yeah but like with C before it had it's bool keyword, people is already producing multiple conflicting definitions of them here.... :S -- Experience is a good school but the fees are high. - Heinrich Heine
Jun 03 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
As you (Walter) know from "Imperfect C++", and I'm sure from posts here as well,
I don't ever advocate a boolean test of truth be an evaluation of == 1. Given
that, where's the need, *ever*, to ensure that an int-sized boolean variable
have
1 or 0. I've always maintained that such a boolean would have 0 or !0.

Given that, I'm dumbfounded (or maybe just dumb) to understand how the int-sized
bool ever costs more (speed) than the bit-sized bool. Conversely, I have
previously stated how the bit-sized can have (speed) costs over the int-sized.

I'm being quite genuine - I'd like someone to explain to me what I've missed.
Plainly put, can anyone demonstrate a single instance where a bit-sized bool can
be more speed efficient than an int-sized bool, when the int-sized bool is only
ever tested as 0 or !0?


"Walter" <newshound digitalmars.com> wrote in message
news:c9lrlu$k74$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c9ln6r$du0$1 digitaldaemon.com...
 As you well know, from reviewing "Imperfect C++", I think C/C++ have made

 mistake by not prescribing that sizeof(bool) == sizeof(int), and why

 manufacturers have "utilised" that missing prescription to blunder and

 sizeof(bool) == 1.

Your argument that sizeof(bool) should be fixed and not left up to the implementation is sound, and is done in D. Your other argument that bool should be the same size as int for efficiency reasons isn't as compelling. To convert an into a bool requires something equivalent to (i?1:0), regardless of the size of the bool. Having random bool variables be int sized is no problem, but having arrays of them is a problem.
 I don't advocate that D do either of these things - i.e. fail to prescribe

 size and presribe/use it as 1 - but D actually goes even further from the

 situation with sizeof(bool), since it defines it as a bit. This merely

 the problems of having it as == 1, and adds the new hassles of addressing
 elements in arrays of "bool"s.

A 'bit' by itself has a size of 1 byte. Only when turned into an array are they packed into bit positions in memory. While this doesn't address the bit array slicing problem, it seems to work rather well otherwise.
 Also, the bit/int opEquals() point is well made.



 instructions:
     cmp    EAX,1
     sbb    EAX,EAX
     inc    EAX
 When sorting/searching a lot of data, this can add up.


 why the bool alias should be int?

No, because even if it is an int it still has to go through the (i?1:0) operation.
 Well, I know you're skin's even thicker than mine, but you clearly _seem_

 point of some exasperation to state that "and it's going to stay that way.
 There's a lot of very cool stuff coming for D, and I can't wait to get it
 implemented. I've had as much as I can take on the whole 15 years of bool
 business".
 That reads to me like "I'm sick of this debate. I'm not changing my mind.

 should all (let me) get on with more important things."

Ok, I can see how you read it that way. But I just wanted to point out that, while it's fun debating these things, it's time for D to move on.
 If conditional
 (sub-)expressions are boolean, and not convertible to int

What's the problem with converting them to int? Why pretend it isn't what it is, a 1 or a 0? I've built TTL hardware, single board computers from scratch, etc., and 0/1, true/false, on/off, yes/no, +5V/0V are all the same in my mind. (In fact, the only reason true and false are keywords in D is not because they are that useful, but because so many programmers believe they are useful <g> and would otherwise produce multiple conflicting definitions of them. It's also there to drive a stake in the heart of the execrable BASIC convention that true is 0xFFFF, and to thwart the equally miserable attempts to make tristate or even quadstate 'bools'.)
 Now here's an idea. We (almost) all agree that we don't want pragmas,

 compiler-options that basically change the definition of the language.

 since we're in the pre-1.0 stage, why not allow a compiler

 that will switch on a boolean type, sub-expressions and switch off
 interconversions. Then we can test, rather than debate, just how
 beneficial/onerous this stuff would be.

Having an alias of bool to int will mean that one could, for example, store '3' in a so-called bool. This is just no good. A bool needs to be constrained to be 0 or 1, or it isn't a bool. The D 'bit' type enforces this constraint, and so is the bool candidate. The basic problem is there are tradeoffs with the semantics of bool and its implementation. Any time there are tradeoffs, there will be controversy. There is no design for it that will put things to rest once and for all.
 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


 that pinpoints the problem, the solution is explained, and one goes on.


 will not happen if implicit conversion rules are changed

Not based on any of the changes I'd want. The compiler would simply fail

 compile on the formerly-convertible expression. Nothing subtle about that.

That's true for implicit narrowing conversions.
 The ABI will happen, it's just premature.


 not done so yet.

It's actually quite a bit of work to write.
 True. And in the spirit of that, I will formally state that, despite my
 disagreeing with it, I can live with the implicit conversions between bool

 int. What I cannot live with, and won't program to, is the fact that the

 type (or alias) bool is a bit. This means that in all my D coding I'm

 have to continue to define the "boolean" type, based on int, albeit that I

 move (and have already in the recent upgrade of recls) from it being a

 being an alias.

All right.
 Can you meet me (/ us) halfway, and at least change the standard alias of

 from bit to int, and I can jettison all my "boolean"-based code?

Ack <g>

Jun 03 2004
next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <c9n2o6$2cui$2 digitaldaemon.com>, Matthew says...

I'm being quite genuine - I'd like someone to explain to me what I've missed.
Plainly put, can anyone demonstrate a single instance where a bit-sized bool can
be more speed efficient than an int-sized bool, when the int-sized bool is only
ever tested as 0 or !0?

I'm not an expert, too, but I think the problem is this last assuption. Evaluating boolean expressions based on the assumption (0, !0) is more complicated that based on the assumption (0, 1). A logical-and could be a bit-and, for example, while in the former case more math is needed. Representing a bool with a bit means ensuring it's in the range (0, 1), so boolean algebra can be optimized. It's only a supposition, because short-circuit evaulation can complicate this assumption. We need an expert that analyzes both implementations. I also understand that accepting to work with (0, !0) gives somewhat surprising results, such as: union T { int i; bool b; }; T a; T b; a.i = 10; b.i = 20; if (a.i != b.i && a.b == b.b) { // this is true! } I also don't know how to compute boolean expressions, such as the equality test between booleans, without prior converting them in the range (0, 1). Ideas? Ciao
Jun 03 2004
parent reply Lord Syl <Lord_member pathlink.com> writes:
Ok, let's get this simple. 
What's wrong with (true/false) for boolean expressions, as Java does?
Jun 03 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
There are two issues at stake:

1. Whether boolean is a distinct type, not implcitly interconvertible with
integral types, and which represents the type of conditional sub-expressions.

2. The sizeof the boolean type.

Your comment seems to pertain to the first. My answer is that, overall, there's
nothing wrong with it, although it does lead to less terse code. I, along with
almost everyone else who's voiced an opinion, am willing to swallow the
verbosity
to avoid the (many) implicit conversion pitfalls. Walter, alas, is not. So
that's
going to pretty much stay.

The second issue is one where there is more (apparent) equivocation. I believe
sizeof(bit) should be sizeof(int). Others do not. AFAICT, it's about 60:40.
Walter's in the 40 on this one as well, though, so it's still 0:100 in real
terms. <G>

Anyway, I am intending to try and divorce myself from this head-banging debate,
as it's just too time consuming, and never gets any traction. If I post any more
opinions, someone please remind me to save my cakehole for cake.

"Lord Syl" <Lord_member pathlink.com> wrote in message
news:c9n9e1$2mil$1 digitaldaemon.com...
 Ok, let's get this simple.
 What's wrong with (true/false) for boolean expressions, as Java does?

Jun 03 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

I'm being quite genuine - I'd like someone to explain to me what I've missed.
Plainly put, can anyone demonstrate a single instance where a bit-sized bool can
be more speed efficient than an int-sized bool, when the int-sized bool is only
ever tested as 0 or !0?
  

then one bit packed together. void funcA(byte x, bit a) { ... } void funcB(byte x, int a) { ... } It's funcA is more efficient when copying on to the stack then funcB as A only requires 16bits and B requires 40bits. Obviously the unpacking has a cost though, although it is often much cheaper to unpack something in the cpu registers then to have it already unpacked in memory. Obviously efficiency can't happen at a test unless you are testing more then one packed value. -- -Anderson: http://badmama.com.au/~anderson/
Jun 03 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <c9n2o6$2cui$2 digitaldaemon.com>, Matthew says...
As you (Walter) know from "Imperfect C++", and I'm sure from posts here as well,
I don't ever advocate a boolean test of truth be an evaluation of == 1. Given
that, where's the need, *ever*, to ensure that an int-sized boolean variable
have
1 or 0. I've always maintained that such a boolean would have 0 or !0.

Technically, if a bool is represented by a single bit, then the values of 0 and 1 are equivalent to 0 and !0 :)
Given that, I'm dumbfounded (or maybe just dumb) to understand how the int-sized
bool ever costs more (speed) than the bit-sized bool. Conversely, I have
previously stated how the bit-sized can have (speed) costs over the int-sized.

I'm being quite genuine - I'd like someone to explain to me what I've missed.
Plainly put, can anyone demonstrate a single instance where a bit-sized bool can
be more speed efficient than an int-sized bool, when the int-sized bool is only
ever tested as 0 or !0?

Never, as far as I know. The size of bool is typically unspecified to allow for it to be optimally adapted to different platforms (and for space). Performance isn't always an issue. Though perhaps this is a case for a pragma--allow the programmer to specify the size of bool? Assume bool is always 0 or !0 (in the case of bit this would be 0 or 1, logically if not physically) and go from there. Sean
Jun 03 2004
prev sibling parent reply Rex Couture <Rex_member pathlink.com> writes:
May I interject with an opinion from an outsider?.  You all live and breath
programming, I suppose with a fairly limited number of languages.  As a
scientist, I use programming seriously as a tool that must be as reliable as
possible.  I only program part time, and I often have to read, decipher, and
write code in multiple languages.  Generally, they are so diverse and so full of
quirks and cute tricks that this is sometimes quite challenging, to say the
least.

If you really want to expand the usefulness of D, you need to exert constant
effort keep it simple and don't get fancy.  What I see in the boolean debate is
anything but simple.  Let me reiterate a couple of principles (or opinions, if
you like) that you have heard many times, and then add some comment on some
obvious(?) pitfalls.

*****************************************************************************
1. A boolean type should have only two values:  true and false.
2. There should be only one boolean type, and it should be called "boolean" or
"bool".
3. Logical statements such as if ...  and while ... should require a boolean
expression, for example 'if (i==1) {}' .
*****************************************************************************

Reality as I see it
1. It seems quite apparent to me that any language that violates rule 3 is
subject to the most insidious type errors that compilers are supposed to catch,
for example:
while aChoice do {something};

You thought aChoice was boolean, but maybe it's not!  What happened to type
safety?

2. Another example:
if (i=3) {...}  //Typing error causes infinite loop.  Compiler is clueless.

3. Arithmetic on boolean variables is mind-boggling.  What use is a boolean
variable that can have values of true, false, or 99?  It may seem simple to you,
but it can require quite a bit of deciphering to someone who didn't write the
code.  Some of you have asked, "What's the big deal?".  It has already been
shown that if it can be done, someone will want to do it, and someone else will
have trouble deciphering it.

I've been programming a fair amount for about 20 years.  I have never seen a
logical operation that couldn't be accomplished simply and with clarity by
adhering to the above principles.  If any of these principles is incompatible
with existing code in some preexisting language, well, so be it.  Maybe it's
time to break it.  Apparently I'm not alone in my opinion.

As for practical matters such as speed, I don't care how boolean variables are
implemented internally, whether a boolean is a bit or a byte, if true is 0 or 1,
whether it's compared to 0 or whatever.  Is it not possible to create efficient
code with boolean type safety?
Jun 03 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 3 Jun 2004 23:39:37 +0000 (UTC), Rex Couture 
<Rex_member pathlink.com> wrote:

 May I interject with an opinion from an outsider?.  You all live and 
 breath
 programming, I suppose with a fairly limited number of languages.  As a
 scientist, I use programming seriously as a tool that must be as 
 reliable as
 possible.  I only program part time, and I often have to read, decipher, 
 and
 write code in multiple languages.  Generally, they are so diverse and so 
 full of
 quirks and cute tricks that this is sometimes quite challenging, to say 
 the
 least.

 If you really want to expand the usefulness of D, you need to exert 
 constant
 effort keep it simple and don't get fancy.  What I see in the boolean 
 debate is
 anything but simple.  Let me reiterate a couple of principles (or 
 opinions, if
 you like) that you have heard many times, and then add some comment on 
 some
 obvious(?) pitfalls.

 *****************************************************************************
 1. A boolean type should have only two values:  true and false.
 2. There should be only one boolean type, and it should be called 
 "boolean" or
 "bool".
 3. Logical statements such as if ...  and while ... should require a 
 boolean
 expression, for example 'if (i==1) {}' .
 *****************************************************************************

 Reality as I see it
 1. It seems quite apparent to me that any language that violates rule 3 
 is
 subject to the most insidious type errors that compilers are supposed to 
 catch,
 for example:
 while aChoice do {something};

 You thought aChoice was boolean, but maybe it's not!  What happened to 
 type
 safety?

 2. Another example:
 if (i=3) {...}  //Typing error causes infinite loop.  Compiler is 
 clueless.

 3. Arithmetic on boolean variables is mind-boggling.  What use is a 
 boolean
 variable that can have values of true, false, or 99?  It may seem simple 
 to you,
 but it can require quite a bit of deciphering to someone who didn't 
 write the
 code.  Some of you have asked, "What's the big deal?".  It has already 
 been
 shown that if it can be done, someone will want to do it, and someone 
 else will
 have trouble deciphering it.

 I've been programming a fair amount for about 20 years.  I have never 
 seen a
 logical operation that couldn't be accomplished simply and with clarity 
 by
 adhering to the above principles.  If any of these principles is 
 incompatible
 with existing code in some preexisting language, well, so be it.  Maybe 
 it's
 time to break it.  Apparently I'm not alone in my opinion.

 As for practical matters such as speed, I don't care how boolean 
 variables are
 implemented internally, whether a boolean is a bit or a byte, if true is 
 0 or 1,
 whether it's compared to 0 or whatever.  Is it not possible to create 
 efficient
 code with boolean type safety?

Rex: Very well said, take a look at a post by "Kris" entitled "The very last thing(s) I'll say about bool is ..." this and that post are very similar. IMO you're both correct. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 03 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c9ln6r$du0$1 digitaldaemon.com...
...
 Well, I know you're skin's even thicker than mine, but you clearly _seem_

 point of some exasperation to state that "and it's going to stay that way.
 There's a lot of very cool stuff coming for D, and I can't wait to get it
 implemented. I've had as much as I can take on the whole 15 years of bool
 business".

Can i be curious and ask what "cool stuff"? I am really interested :)
Jun 03 2004
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <c9ln6r$du0$1 digitaldaemon.com>, Matthew wrote:
 As you well know, from reviewing "Imperfect C++", I think C/C++ have made a
grave
 mistake by not prescribing that sizeof(bool) == sizeof(int), and why compiler
 manufacturers have "utilised" that missing prescription to blunder and defined
 sizeof(bool) == 1.

Is it bad that sizeof(bool) == 1? What should the size of bool be? The size of machine word? Byte is the minimal addressable element, so it would be logical to use it, right? There are char, short, and byte as well... -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
Jun 04 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9k3ah$13fo$1 digitaldaemon.com>, Kris says...
BTW: according to your 'handle', you appear to claim some heritage to the
proverbial "Arc Angel". If so, perhaps you might consider setting a higher
standard? These personal attacks are just so boring ...

Whoa! I have never made a personal attack against /anyone/ on this forum, and I never intend to. Any offense taken by anyone is absolutely not my intention. I have only the highest praise and admiration for Walter. Jill
Jun 02 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
He he. Never say never.

Nearly everyone on this group is great, but there are one or two ...


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9kcog$1glr$1 digitaldaemon.com...
 In article <c9k3ah$13fo$1 digitaldaemon.com>, Kris says...
BTW: according to your 'handle', you appear to claim some heritage to the
proverbial "Arc Angel". If so, perhaps you might consider setting a higher
standard? These personal attacks are just so boring ...

Whoa! I have never made a personal attack against /anyone/ on this forum, and I never intend to. Any offense taken by anyone is absolutely not my intention. I have only the highest praise and admiration for Walter. Jill

Jun 02 2004
prev sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Arcane Jill" wrote:
 Whoa! I have never made a personal attack against /anyone/ on this forum,

 never intend to. Any offense taken by anyone is absolutely not my

 have only the highest praise and admiration for Walter.

You know, it's tough to pick up cues in a disembodied environment. If I misunderstood you completely, then I proffer apologies. Having said that, your post was in reply to Walter's request/plea for us all to move on. Given that, I felt your reply was obnoxious at best. My mistake. Regarding opEquals(): if you'd be content with it returning a bool/bit instead, then may I humbly suggest you post a bug report regarding its inconsistency? That way, it might stand a better chance of not falling through the cracks. Regards; ---------- Outgoing message is certified Acid Free
Jun 02 2004
prev sibling next sibling parent reply hellcatv hotmail.com writes:
while I agree that bool is ambiguous I think most people would prefer it aliased
to int rather than bit in object.d :-)
can we override it in a general sense so it will compile elsewhere? (i.e. alias
int bool; and not have conflicts with the bit bool in the object.d  ... also the
last thing I would want is to have problems like libjpeg of bool being char
somewhere and int otherwhere and bit thirdware)

--Daniel

In article <c9k035$v8g$1 digitaldaemon.com>, Arcane Jill says...
In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter. There have been many different suggestions regarding *implementation* - and if you want to call that "no consensus" then that's your viewpoint - but regarding the principle that a bool is not arithmetic, if you have been following this forum, you'll know you are in a very small minority here. If we have to wait until someone implements the SECOND D-compiler before we see a bool type, then so be it. But I'll bet you any amount of money you like it will be in the ISO/ANSI standard which eventually supercedes the original implementation. I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the face. Unless you are defining "consensus" as "unanimous opinion" - in which case your comment "and therefore no resolution" is absurd. Arcane Jill

Jun 02 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
<hellcatv hotmail.com> wrote in message
news:c9kd4u$1h85$1 digitaldaemon.com...
 while I agree that bool is ambiguous I think most people would prefer it

 to int rather than bit in object.d :-)
 can we override it in a general sense so it will compile elsewhere? (i.e.

 int bool; and not have conflicts with the bit bool in the object.d  ...

 last thing I would want is to have problems like libjpeg of bool being

 somewhere and int otherwhere and bit thirdware)

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.
Jun 02 2004
prev sibling next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <c9kd4u$1h85$1 digitaldaemon.com>, hellcatv hotmail.com says...
while I agree that bool is ambiguous I think most people would prefer it aliased
to int rather than bit in object.d :-)
can we override it in a general sense so it will compile elsewhere? (i.e. alias
int bool; and not have conflicts with the bit bool in the object.d  ... also the
last thing I would want is to have problems like libjpeg of bool being char
somewhere and int otherwhere and bit thirdware)

OK, so now officially starts the D bool nightmare. Having fought for 10+ years with the C bool nightmare, I admit I'm not happy. Once I spent a week or so trying to get 3 different kind of bool, Bool and BOOL work with the various true, True, TRUE, false, False, FALSE and whatever. The fact that programmers kept writing if (expr == True/TRUE/false...) was another source for bugs. For me it's astonishing that experienced C programmers think that having a true bool type is not useful. Most of the library I've seen defined their own kind of boolean type (when you're lucky it's 'typedef int', but I've also seen ' #define char', or 'void *'), and unaware programmers did the rest of the work. I pray for a boolean type, whatever the implementation, giving all D programs and libraries consistency. Ciao
Jun 03 2004
prev sibling parent "Bruno A. Costa" <bruno codata.com.br> writes:
hellcatv hotmail.com wrote:

 while I agree that bool is ambiguous I think most people would prefer it
 aliased to int rather than bit in object.d :-)

I don't think it is a good idea: alias int bool; bool b; b = 5; // ????? with bool being an alias to bit, things are more consistent: alias bit bool; bool b; b = 5; // Compile time error: cannot implicitly convert int to bit Bruno.
 can we override it in a general sense so it will compile elsewhere? (i.e.
 alias
 int bool; and not have conflicts with the bit bool in the object.d  ...
 also the last thing I would want is to have problems like libjpeg of bool
 being char somewhere and int otherwhere and bit thirdware)
 
 --Daniel
 
 In article <c9k035$v8g$1 digitaldaemon.com>, Arcane Jill says...
In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees

This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter. There have been many different suggestions regarding *implementation* - and if you want to call that "no consensus" then that's your viewpoint - but regarding the principle that a bool is not arithmetic, if you have been following this forum, you'll know you are in a very small minority here. If we have to wait until someone implements the SECOND D-compiler before we see a bool type, then so be it. But I'll bet you any amount of money you like it will be in the ISO/ANSI standard which eventually supercedes the original implementation. I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the face. Unless you are defining "consensus" as "unanimous opinion" - in which case your comment "and therefore no resolution" is absurd. Arcane Jill


Jun 03 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 2 Jun 2004 07:37:10 +0000 (UTC), Arcane Jill wrote:

 In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees


[snip]
 - but regarding
 the principle that a bool is not arithmetic, if you have been following this
 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!" It is *so* Douglas Adams/Monty Python/Lewis Carroll ! -- Derek 3/Jun/04 11:59:01 AM Truth is not a number.
Jun 02 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 3 Jun 2004 12:21:24 +1000, Derek Parnell <derek psych.ward> wrote:
 On Wed, 2 Jun 2004 07:37:10 +0000 (UTC), Arcane Jill wrote:

 In article <c9j8jo$2t58$1 digitaldaemon.com>, Walter says...
 There is no consensus, nobody agrees


[snip]
 - but regarding
 the principle that a bool is not arithmetic, if you have been following 
 this
 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!" It is *so* Douglas Adams/Monty Python/Lewis Carroll !

This works in C++ also, simply change "char[]" to "char *", you even get the same results. (tho it depends on what the compiler does with those static strings!) I think we can all agree 'bool' is not an arithmetic type. Can't we? Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 02 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:c9m1v3$sv4$1 digitaldaemon.com...
 - but regarding
 the principle that a bool is not arithmetic, if you have been following


 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!"

Here are some uses that I use now and then: -------------------------------- 1) Assembling a 'flags variable' from boolean components: bool Carry; bool Overflow; uint flags = (Carry << 6) | Overflow; 2) Add booleans to state variable to, for example, conditionally advance to the next state in a state machine: state += (foo == bar); 3) Use bools as an index into an array: char[] response[2]; printf("answer is %.*s\n", response[ foo == bar ]); ------------------------------------ Of course, these can all be uglified with cast(int)b, or with (b?1:0), but I just don't see the paradigm problem with bool being a 1 or a 0 integer.
Jun 02 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 2 Jun 2004 20:00:26 -0700, Walter wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:c9m1v3$sv4$1 digitaldaemon.com...
 - but regarding
 the principle that a bool is not arithmetic, if you have been following


 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!"

Here are some uses that I use now and then: -------------------------------- 1) Assembling a 'flags variable' from boolean components: bool Carry; bool Overflow; uint flags = (Carry << 6) | Overflow;

And I would have coded it more explicitly... uint flags = (Carry ? 1<<6 : 0) | (Overflow? 1 : 0); or maybe even ... flags = 0; if (Carry ) flags |= 1<<6; if (Overflow) flags |= 1;
 2) Add booleans to state variable to, for example, conditionally advance to
 the next state in a state machine:
 
     state += (foo == bar);

Not explict enough for my 'self-documenting code' standards. if (foo == bar) state += 1;
 3) Use bools as an index into an array:
 
 char[] response[2];
 printf("answer is %.*s\n", response[ foo == bar ]);

printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]); or char[] response[2]; char[] msg; // Because one day there might be more than two potential messages. switch (foo) { case foo: msg = response[0]; break; default: msg = response[1]; }; printf("answer is %.*s\n", msg);
 ------------------------------------
 Of course, these can all be uglified with cast(int)b, or with (b?1:0),

"uglified"? One person's "ugly" is another person "documentation" ;-)
 but I just don't see the paradigm problem with bool being a 1 or a 0 integer.

True, its just a way of thinking. A metaphor, if you will. I prefer writing code that other people can easily read, so that they can understand my intentions. Brevity, for its own sake, does not guarentee legibilty. I would always prefer clearest code over fastest code. -- Derek 3/Jun/04 1:27:35 PM
Jun 02 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:c9m71a$149k$1 digitaldaemon.com...
 Of course, these can all be uglified with cast(int)b, or with (b?1:0),


I'll have you know I have just patented "uglified" and y'all owe me royalties!
 I prefer writing code that other people can easily read, so that they can
 understand my intentions. Brevity, for its own sake, does not guarentee
 legibilty.
 I would always prefer clearest code over fastest code.

And of course, I think the way I wrote it is clearer <g>.
Jun 02 2004
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <c9mi5r$1kiu$1 digitaldaemon.com>, Walter wrote:
 And of course, I think the way I wrote it is clearer <g>.

I suppose there's nothing wrong defining implicit casts from bool to int. After all, we have casts from int to float as well. Even from char to int! However, if int is implicitly castable to bool, then the infamous "while (x = 1) { ... }" raises its ugly head. -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
Jun 04 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
All this just goes to show that bit are cleaner to read as they are now.

Derek Parnell wrote:

On Wed, 2 Jun 2004 20:00:26 -0700, Walter wrote:

  

"Derek Parnell" <derek psych.ward> wrote in message
news:c9m1v3$sv4$1 digitaldaemon.com...
    

- but regarding
the principle that a bool is not arithmetic, if you have been following
        


forum, you'll know you are in a very small minority here.
        

{ char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!"

-------------------------------- 1) Assembling a 'flags variable' from boolean components: bool Carry; bool Overflow; uint flags = (Carry << 6) | Overflow;

And I would have coded it more explicitly... uint flags = (Carry ? 1<<6 : 0) | (Overflow? 1 : 0); or maybe even ... flags = 0; if (Carry ) flags |= 1<<6; if (Overflow) flags |= 1;
2) Add booleans to state variable to, for example, conditionally advance to
the next state in a state machine:

    state += (foo == bar);
    

Not explict enough for my 'self-documenting code' standards. if (foo == bar) state += 1;
3) Use bools as an index into an array:

char[] response[2];
printf("answer is %.*s\n", response[ foo == bar ]);
    

printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]); or char[] response[2]; char[] msg; // Because one day there might be more than two potential messages. switch (foo) { case foo: msg = response[0]; break; default: msg = response[1]; }; printf("answer is %.*s\n", msg);
------------------------------------
Of course, these can all be uglified with cast(int)b, or with (b?1:0),
    

"uglified"? One person's "ugly" is another person "documentation" ;-)
but I just don't see the paradigm problem with bool being a 1 or a 0 integer.
    

True, its just a way of thinking. A metaphor, if you will. I prefer writing code that other people can easily read, so that they can understand my intentions. Brevity, for its own sake, does not guarentee legibilty. I would always prefer clearest code over fastest code.

-- -Anderson: http://badmama.com.au/~anderson/
Jun 03 2004
prev sibling parent reply Charlie <Charlie_member pathlink.com> writes:
Like you say, its a matter if opionon,

 uint flags = (Carry << 6) | Overflow;

is far easier for me to read then
      flags = 0;      
      if (Carry )
          flags |= 1<<6;
      if (Overflow)
          flags |= 1;

  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);

Look at all that repetition! ;). Charles In article <c9m71a$149k$1 digitaldaemon.com>, Derek Parnell says...
On Wed, 2 Jun 2004 20:00:26 -0700, Walter wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:c9m1v3$sv4$1 digitaldaemon.com...
 - but regarding
 the principle that a bool is not arithmetic, if you have been following


 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!"

Here are some uses that I use now and then: -------------------------------- 1) Assembling a 'flags variable' from boolean components: bool Carry; bool Overflow; uint flags = (Carry << 6) | Overflow;

And I would have coded it more explicitly... uint flags = (Carry ? 1<<6 : 0) | (Overflow? 1 : 0); or maybe even ... flags = 0; if (Carry ) flags |= 1<<6; if (Overflow) flags |= 1;
 2) Add booleans to state variable to, for example, conditionally advance to
 the next state in a state machine:
 
     state += (foo == bar);

Not explict enough for my 'self-documenting code' standards. if (foo == bar) state += 1;
 3) Use bools as an index into an array:
 
 char[] response[2];
 printf("answer is %.*s\n", response[ foo == bar ]);

printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]); or char[] response[2]; char[] msg; // Because one day there might be more than two potential messages. switch (foo) { case foo: msg = response[0]; break; default: msg = response[1]; }; printf("answer is %.*s\n", msg);
 ------------------------------------
 Of course, these can all be uglified with cast(int)b, or with (b?1:0),

"uglified"? One person's "ugly" is another person "documentation" ;-)
 but I just don't see the paradigm problem with bool being a 1 or a 0 integer.

True, its just a way of thinking. A metaphor, if you will. I prefer writing code that other people can easily read, so that they can understand my intentions. Brevity, for its own sake, does not guarentee legibilty. I would always prefer clearest code over fastest code. -- Derek 3/Jun/04 1:27:35 PM

Jun 03 2004
parent Sean Kelly <sean f4.ca> writes:
In article <c9nj0i$3ph$1 digitaldaemon.com>, Charlie says...
Like you say, its a matter if opionon,

 uint flags = (Carry << 6) | Overflow;

is far easier for me to read then
      flags = 0;      
      if (Carry )
          flags |= 1<<6;
      if (Overflow)
          flags |= 1;

  printf("answer is %.*s\n", response[ (foo == bar ? 0 : 1) ]);

Look at all that repetition! ;).

uint flags = (Carry?1<<6:0) | (Overflow?1:0); Looks pretty clear to me, if perhaps a bit more verbose than Walter's version :) Sean
Jun 03 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Come on, mate. We're entering crazy-land now.

What you've shown are three rare cases when using a boolean as an integral is
useful. I agree that it can be useful, and I recognise at least two of these
idioms myself. But you're now showing extreme bias in your arguments. These are
rare cases, and for which the addition of an "uglifying" cast couldn't be termed
onerous in anyone's imagination, no matter how hard one wants to prove a point.

There is absolutely no way I can take seriously the argument that uses such as
these, easily facilitated by a cast, in any way compensate for the myriad cases
where the convertibility causes problems.

Even were they anything more than about 1 to 1000 in prevalence, the fact is
that
adding the strength to bool would cause you (and me) to use a cast, when
occasionally doing these things. Well, that's good! It makes the code clearer,
not more obtuse.  But leaving things as they are for the sake of these marginal
cases - cause let's be honest, it's not gorgeous code, is it? - means that we're
subject to all the problems encountered in C, and especially C++, whereby a bool
is passed as the length of a string, or the number of elements in a vector<>, or
its "truth" is misrepresented by truncation, etc. etc. etc an infinitum.

Like I've said, at the end of the day I think you're going to say No! to us all
on this bool issue because _you_ don't like it. Fair enough. I don't expect D to
be perfect. If you're putting your foot down, just say so. I still respect you
in
the morning.

But please don't resort to this kind of stuff. Telling us black's white, and
green's somewhere over there isn't going to wash.

:(

"Walter" <newshound digitalmars.com> wrote in message
news:c9m4di$10gd$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward> wrote in message
 news:c9m1v3$sv4$1 digitaldaemon.com...
 - but regarding
 the principle that a bool is not arithmetic, if you have been following


 forum, you'll know you are in a very small minority here.

void main( ) { char[] myHat = "red"; char[] myCoat = "blue"; bool a = (myHat == "red"); bool b = (myCoat == "blue"); int c; c = (3*a) + (b*b); printf("%d %d %d\n",a,b,c); } LOL!!!! Why this code above should compile is beyond my understanding. In English it is like saying "Q:What is the sum of three times (is my hat red?) and the square of (is my coat blue?)? A: 4!"

Here are some uses that I use now and then: -------------------------------- 1) Assembling a 'flags variable' from boolean components: bool Carry; bool Overflow; uint flags = (Carry << 6) | Overflow; 2) Add booleans to state variable to, for example, conditionally advance to the next state in a state machine: state += (foo == bar); 3) Use bools as an index into an array: char[] response[2]; printf("answer is %.*s\n", response[ foo == bar ]); ------------------------------------ Of course, these can all be uglified with cast(int)b, or with (b?1:0), but I just don't see the paradigm problem with bool being a 1 or a 0 integer.

Jun 02 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
       int main()
       {
           bit b = 1;
           ++b;
           printf("%d\n", b);
           return 0;
       }

Prints 2. Jill
Jun 03 2004
parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c9miu4$1mak$1 digitaldaemon.com...
       int main()
       {
           bit b = 1;
           ++b;
           printf("%d\n", b);
           return 0;
       }

Prints 2. Jill

That's a bug.
Jun 03 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
We'll just agree to disagree, then.
Jun 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
It'd be boring any other way, don't ya think? <g>

"Walter" <newshound digitalmars.com> wrote in message
news:c9mnfn$1tc9$1 digitaldaemon.com...
 We'll just agree to disagree, then.

Jun 03 2004
parent "Walter" <newshound digitalmars.com> writes:
I'm bored enough with bool 10 years ago <g>.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c9mucl$26qj$1 digitaldaemon.com...
 It'd be boring any other way, don't ya think? <g>

 "Walter" <newshound digitalmars.com> wrote in message
 news:c9mnfn$1tc9$1 digitaldaemon.com...
 We'll just agree to disagree, then.


Jun 03 2004
prev sibling next sibling parent reply "Les Baker" <lesbaker innovaREMOVETHIS.net> writes:
 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept". <opinion> "bool" being an alias for bit seems to open the way for implementation-defined quirks to pop up. Same with int. The programmer shouldn't need to worry about implementation issues (or how badly his fellow coder/coworker can stretch the rules) for what seems to be such a narrowly-defined logical type. </opinion> (Could be 100% off-base here... don't flame too hard. Just my $0.02) Les Baker
Jun 02 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9mbn7$1c1u$1 digitaldaemon.com>, Les Baker says...
 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc?

Done it. The type is called Bool.
What would be needed in the language to do so?

import etc.workaround.types;
Is it already in D (opCast, making arithemetic operators private)?

It's in Deimos.
remember in CUJ reading an article Herb Sutter wrote (I think) about the
"nullptr" keyword proposal, and it mentioned that several library based
solutions were tried before proposing a new keyword. Maybe such a type could
be a "proof-of-concept".

Feel free to try it out. All of the boolean operations in the Int class now use Bool instead of bool, boolean or int. Bools will *not* auto-convert either to or from ints, but they can be used in flow-control statements like if (b)... Code is at http://www.fast-forward.info/ramonsky/stuff/d/bigint.html. This includes the Bool type. Arcane Jill PS.
<opinion> "bool" being an alias for bit seems to open the way for
implementation-defined quirks to pop up. Same with int. The programmer
shouldn't need to worry about implementation issues (or how badly his fellow
coder/coworker can stretch the rules) for what seems to be such a
narrowly-defined logical type. </opinion>

I don't care whether D's bool is aliased to bool or to int. I do care that the value returned by D's opEquals() does not auto-cast to D's bool.
Jun 03 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Les Baker wrote:

 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".

There should be only one bool (with possible aliases) - otherwise the library becomes unusable. Users will always have to ask themselves "do I pass a bool or a Bool? do I provide overloaded methods accepting bool and Bool or do I just choose one? which one?" It is much better long-term to just choose one globally.
 <opinion> "bool" being an alias for bit seems to open the way for
 implementation-defined quirks to pop up. Same with int. The programmer
 shouldn't need to worry about implementation issues (or how badly his
 fellow coder/coworker can stretch the rules) for what seems to be such a
 narrowly-defined logical type. </opinion>
 
 (Could be 100% off-base here... don't flame too hard. Just my $0.02)
 
 Les Baker

Jun 03 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
news:c9mbn7$1c1u$1 digitaldaemon.com...
 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".

STLSoft has a library-based version of the null pointer, which works perfectly well in all circumstances. It's explained in "Imperfect C++", and one of the publisher's reviewers, who's on the C++ standards committee, asked if he could present the material to the standards committee. I've not heard anything since that time, and suspect it'll be rejected anyway, as it has one sneaky albeit, IMO, utterly reasonable, trick. But I'd better shut up, as the publisher'll be on my back for revealing all the juicy bits from the book before it hits the shelves (Sept 9th). Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael Gibbs -------------------------------------------------------------------------------
Jun 03 2004
next sibling parent reply Lord Syl <Lord_member pathlink.com> writes:
In article <c9n5ik$2h0d$1 digitaldaemon.com>, Matthew says...
"Les Baker" <lesbaker innovaREMOVETHIS.net> wrote in message
news:c9mbn7$1c1u$1 digitaldaemon.com...
 The D options are:

 1) use bit which has only 'true' or 'false' values
 2) use int which has !0 and 0 values (the C style)
 3) use bool for those who don't think that bit is self-documenting <g>

Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".

STLSoft has a library-based version of the null pointer, which works perfectly well in all circumstances. It's explained in "Imperfect C++", and one of the publisher's reviewers, who's on the C++ standards committee, asked if he could present the material to the standards committee. I've not heard anything since that time, and suspect it'll be rejected anyway, as it has one sneaky albeit, IMO, utterly reasonable, trick. But I'd better shut up, as the publisher'll be on my back for revealing all the juicy bits from the book before it hits the shelves (Sept 9th). Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael Gibbs -------------------------------------------------------------------------------

Boolean expressions as part of the library? That's counterproductive: As a example, one of the advantages of D is that strings are directly built into the core. Then, if we do the opposite with something as basic as boolean expressions, we are improving here then screw there. Bad idea.
Jun 03 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9na1h$2nf1$1 digitaldaemon.com>, Lord Syl says...

Boolean expressions as part of the library? That's counterproductive:
As a example, one of the advantages of D is that strings are directly built into
the core. 
Then, if we do the opposite with something as basic as boolean expressions, we
are improving here then screw there. Bad idea.

So don't use my class. I'm not forcing you. But please don't tell me not to write the code that I want to use. If it want it, and it does not exist, I will write it, and I will use it. If I could figure out a way to write a class that made toast and smothered it in strawberry jam, I'd write that too. I don't CARE if other people don't use it. They're not who I'm writing it for. I wrote it for me. Aha - you say - then why put it in a library? Answer - it is required BY MY CODE (which is itself in a library). So really, all I actually did, about which you can complain, is tell people about it. Jill
Jun 03 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <c9n5ik$2h0d$1 digitaldaemon.com>, Matthew says...
STLSoft has a library-based version of the null pointer, which works perfectly
well in all circumstances. It's explained in "Imperfect C++", and one of the
publisher's reviewers, who's on the C++ standards committee, asked if he could
present the material to the standards committee. I've not heard anything since
that time, and suspect it'll be rejected anyway, as it has one sneaky albeit,
IMO, utterly reasonable, trick.

There's been some talk about this in the last two issues of CUJ. Basically, they decided to add they keyword nullptr to the language to allow for meaningful error messages. Usage will likely be pretty much the same as the recent library versions. Sean
Jun 03 2004
next sibling parent Daniel Horn <hellcatv hotmail.com> writes:
on GDC  (linux)
Bool.test(digit.length==2)
actually does not pass in a value of 1 or 0 to your bool test function
then your bool throws a problem.

it seems like your bool implementation is not linux compatible :-(
if I take out that throw it now dies on an infinite loop
perhaps opCast has not yet been made on linux :-/

which means that I'm going to have to fork your BigInteger to use the 
old bit version....can you send me the diffs you did to make the print 
work ... *sigh*
I really liked the old version of this better without all these Big Bools.
sure bit isn't perfect...but having to write Bool.test
can't wait until subversion--then integration wouldn't be such a problem.
--Daniel
Sean Kelly wrote:

 In article <c9n5ik$2h0d$1 digitaldaemon.com>, Matthew says...
 
STLSoft has a library-based version of the null pointer, which works perfectly
well in all circumstances. It's explained in "Imperfect C++", and one of the
publisher's reviewers, who's on the C++ standards committee, asked if he could
present the material to the standards committee. I've not heard anything since
that time, and suspect it'll be rejected anyway, as it has one sneaky albeit,
IMO, utterly reasonable, trick.

There's been some talk about this in the last two issues of CUJ. Basically, they decided to add they keyword nullptr to the language to allow for meaningful error messages. Usage will likely be pretty much the same as the recent library versions. Sean

Jun 03 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:c9nn2d$a1l$1 digitaldaemon.com...
 In article <c9n5ik$2h0d$1 digitaldaemon.com>, Matthew says...
STLSoft has a library-based version of the null pointer, which works perfectly
well in all circumstances. It's explained in "Imperfect C++", and one of the
publisher's reviewers, who's on the C++ standards committee, asked if he could
present the material to the standards committee. I've not heard anything since
that time, and suspect it'll be rejected anyway, as it has one sneaky albeit,
IMO, utterly reasonable, trick.

There's been some talk about this in the last two issues of CUJ. Basically, they decided to add they keyword nullptr to the language to allow for

 error messages.  Usage will likely be pretty much the same as the recent

 versions.

But the problem with the new keyword is that it won't be available on old/current compilers, whereas my soln works for pretty much any compiler you can shake a stick at. Anyway, I'm going to shut up about this one, since it'll be far too obviously advertisingly self-aggrandising. ;)
Jun 03 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
I had a brainwave about an hour ago and ditched the Bool class entirely.
Instead, I did this:

typedef void* Bool;
const Bool FALSE = cast(Bool) 0;
const Bool TRUE = cast(Bool) 1;

Ah - the simple ideas are always the best!

And guess what? - Bool now gives me everything I want in terms of compile-time
safety, but, in addition, is about as efficient as it gets. I re-did the tests I
did earlier, and isolated them from each other (because I discovered that the
compiler was doing some optimization even in a debug build in which I hadn't
asked it to). These results are pretty cool:

----------------------------------------
bit b1 = 1;
0040AF74  mov         byte ptr [b1],1 
----------------------------------------
byte b2 = 1;
0040AF80  mov         byte ptr [b2],1 
----------------------------------------
int b3 = 1;
0040AF8C  mov         dword ptr [b3],1 
----------------------------------------
void* b4 = cast(void*)1;
0040AF9C  mov         dword ptr [b4],1 
----------------------------------------
Bool b5 = TRUE;
0040AFAC  mov         dword ptr [b5],1 
----------------------------------------

So all those changes are now online, and I'm leaving it at that. If anyone is
concerned that, for example, my function  isPrime() returns a Bool and not some
other type, remember that you're most likely going to use these things in
statements like:

       if (isPrime(n))
       {
           /* do stuff */
       }

which will compile perfectly anyway. Regarding the Linux incompatibilty problem, I'm surprised that the expression (digit.length==2) yields a value other than 0 or 1. That has to be a bug. The workaround is of course to replace
       toBool(digit.length==2):

(which throws an exception), with
       cast(Bool)(digit.length==2);

which doesn't. Hopefully now no-one can object. A straightforward typedef to void* is at least as reasonable as an alias to int, and has the benefit of type-safety. Arcane Jill
Jun 03 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
yay! now it will work in linux on gdc

Arcane Jill wrote:

 I had a brainwave about an hour ago and ditched the Bool class entirely.
 Instead, I did this:
 
 typedef void* Bool;
 const Bool FALSE = cast(Bool) 0;
 const Bool TRUE = cast(Bool) 1;
 
 Ah - the simple ideas are always the best!
 
 And guess what? - Bool now gives me everything I want in terms of compile-time
 safety, but, in addition, is about as efficient as it gets. I re-did the tests
I
 did earlier, and isolated them from each other (because I discovered that the
 compiler was doing some optimization even in a debug build in which I hadn't
 asked it to). These results are pretty cool:
 
 ----------------------------------------
 bit b1 = 1;
 0040AF74  mov         byte ptr [b1],1 
 ----------------------------------------
 byte b2 = 1;
 0040AF80  mov         byte ptr [b2],1 
 ----------------------------------------
 int b3 = 1;
 0040AF8C  mov         dword ptr [b3],1 
 ----------------------------------------
 void* b4 = cast(void*)1;
 0040AF9C  mov         dword ptr [b4],1 
 ----------------------------------------
 Bool b5 = TRUE;
 0040AFAC  mov         dword ptr [b5],1 
 ----------------------------------------
 
 So all those changes are now online, and I'm leaving it at that. If anyone is
 concerned that, for example, my function  isPrime() returns a Bool and not some
 other type, remember that you're most likely going to use these things in
 statements like:
 
 
      if (isPrime(n))
      {
          /* do stuff */
      }

which will compile perfectly anyway. Regarding the Linux incompatibilty problem, I'm surprised that the expression (digit.length==2) yields a value other than 0 or 1. That has to be a bug. The workaround is of course to replace
      toBool(digit.length==2):

(which throws an exception), with
      cast(Bool)(digit.length==2);

which doesn't. Hopefully now no-one can object. A straightforward typedef to void* is at least as reasonable as an alias to int, and has the benefit of type-safety. Arcane Jill

Jun 03 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Sorry Jill;

I fail to see how your personal version of Bool is particularly typesafe.
For example:

void main()
{
        typedef void* Bool;

        const Bool FALSE = cast(Bool) 0;
        const Bool TRUE = cast(Bool) 1;

        void foo (void *ack)
        {
        }

        Bool b = TRUE;
        foo (b);
}

I just passed a value of 1 as a void pointer argument, without a peep from
the compiler. Is that what you had in mind? Walter's implementation of
bit/bool, catches this test with flying colours ...

Without wishing to be pedantic, you might perhaps find some further reason
to avoid fracturing this issue further within this post:
c9nqcd$f21$1 digitaldaemon.com

Respectfully;

- Kris






"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:c9o87e$13t3$1 digitaldaemon.com...
 yay! now it will work in linux on gdc

 Arcane Jill wrote:

 I had a brainwave about an hour ago and ditched the Bool class entirely.
 Instead, I did this:

 typedef void* Bool;
 const Bool FALSE = cast(Bool) 0;
 const Bool TRUE = cast(Bool) 1;

 Ah - the simple ideas are always the best!

 And guess what? - Bool now gives me everything I want in terms of


 safety, but, in addition, is about as efficient as it gets. I re-did the


 did earlier, and isolated them from each other (because I discovered


 compiler was doing some optimization even in a debug build in which I


 asked it to). These results are pretty cool:

 ----------------------------------------
 bit b1 = 1;
 0040AF74  mov         byte ptr [b1],1
 ----------------------------------------
 byte b2 = 1;
 0040AF80  mov         byte ptr [b2],1
 ----------------------------------------
 int b3 = 1;
 0040AF8C  mov         dword ptr [b3],1
 ----------------------------------------
 void* b4 = cast(void*)1;
 0040AF9C  mov         dword ptr [b4],1
 ----------------------------------------
 Bool b5 = TRUE;
 0040AFAC  mov         dword ptr [b5],1
 ----------------------------------------

 So all those changes are now online, and I'm leaving it at that. If


 concerned that, for example, my function  isPrime() returns a Bool and


 other type, remember that you're most likely going to use these things


 statements like:


      if (isPrime(n))
      {
          /* do stuff */
      }

which will compile perfectly anyway. Regarding the Linux incompatibilty problem, I'm surprised that the


 (digit.length==2) yields a value other than 0 or 1. That has to be a


 workaround is of course to replace


      toBool(digit.length==2):

(which throws an exception), with
      cast(Bool)(digit.length==2);

which doesn't. Hopefully now no-one can object. A straightforward


 void* is at least as reasonable as an alias to int, and has the benefit


 type-safety.

 Arcane Jill


Jun 03 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <c9o5qf$100l$1 digitaldaemon.com>, Matthew says...
But the problem with the new keyword is that it won't be available on
old/current
compilers, whereas my soln works for pretty much any compiler you can shake a
stick at.

Yup. I've seen the library examples and they work just fine. I'll probably begin converting my code now to use one of those so I don't have to deal with it later :) Sean
Jun 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:c9o9bp$15jm$1 digitaldaemon.com...
 In article <c9o5qf$100l$1 digitaldaemon.com>, Matthew says...
But the problem with the new keyword is that it won't be available on


compilers, whereas my soln works for pretty much any compiler you can shake a
stick at.

Yup. I've seen the library examples and they work just fine. I'll probably begin converting my code now to use one of those so I don't have to deal with

 later :)

Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)
Jun 03 2004
parent reply <sean f4.ca> writes:
In article <c9orb9$1uc9$1 digitaldaemon.com>, Matthew says...
Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)

I haven't seen the STLSoft null, but maybe I should wait for it :) I saw a templatized version that IIRC Scott Meyers wrote and perhaps one other. Sean
Jun 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
<sean f4.ca> wrote in message news:c9q3ht$rst$1 digitaldaemon.com...
 In article <c9orb9$1uc9$1 digitaldaemon.com>, Matthew says...
Do you mean the STLSoft null? If so, cool! :) If not, what do you mean? :)

I haven't seen the STLSoft null, but maybe I should wait for it :) I saw a templatized version that IIRC Scott Meyers wrote and perhaps one other.

It's been in there for a couple of years! Look at stlsoft_null.h and stlsoft_nulldef.h. It works perfectly with 26 different compilers, enforcing that NULL is only ever copied to, or compared with, a pointer. It's one of my favourite inventions, and has discovered hundreds of errors since I've been using it. I might humbly say that less than 20 of those were in my own code; the rest were in library code from many famous vendors, but self-preservation prevents me from saying who. (They include companies with very large budgets, and *very* large user bases.) It's all covered in chapter 15 of "Imperfect C++". I don't know if I've mentioned it before, but I've recently written a book ... Rita the Repeater Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) Director, Synesis Software (www.synesis.com.au) STLSoft moderator (http://www.stlsoft.org) -----------------------------------------------------
Jun 04 2004
parent "KTC" <me here.com> writes:
 It's all covered in chapter 15 of "Imperfect C++". I don't know if I've

 it before, but I've recently written a book ...

Stop teasing, 3 months is a long time to wait..... :P
Jun 04 2004
prev sibling parent Rex Couture <Rex_member pathlink.com> writes:
If I understand correctly, Walter is adamant about retaining the present boolean
philosophy because it gives him the speed and flexibility he wants, it looks and
smells like C, and besides, he probably doesn't want to make any changes.

I think it's also a fair statement that many of the users are equally adamant
that any programming language must be type-safe with regard to conditional
statements, that a conditional statement should therefore require a boolean
expression, and that there should only be one boolean type, which must have an
obvious name.

I don't think we can convince Walter about the language requirements, but
presumably he is sensitive to the need to accommodate users' requirements.

There is a simple compromise that should satisfy everyone.  I strongly suggest a
boolean type, called "boolean" or "bool", which is defined as part of the
language.  Use of a nonboolean expression in a conditional statement should draw
a mandatory compiler warning.

A compromise is probably the only way to fix the problem, under the
circumstances.  So what do you say, Walter?  You always said this is a practical
language, not for purists.  How much more practical can you get, to
simultaneously satisfy both the machine-language types and those who demand type
safety?
Jun 09 2004
prev sibling next sibling parent reply "Dennis Walters, II" <scruff myrealbox.com> writes:
On Tue, 1 Jun 2004 17:47:13 -0700
"Walter" <newshound digitalmars.com> wrote:

 I've had as much as I can take on the whole 15 years of bool business,
 I've got the scars to prove it <g>.

Yeah, but do you have photos to prove that you've got the scars to prove it? :o) Dennis
Jun 01 2004
parent Juan C <Juan_member pathlink.com> writes:
Yeah, but do you have photos to prove that you've got the scars to prove
it?

Some of the scars are on his backside, I don't want to see them.
Jun 01 2004
prev sibling next sibling parent reply James McComb <alan jamesmccomb.id.au> writes:
Arcane Jill wrote:

 I've just noticed that the keyword "bool" is accepted by the compiler. Turns
out
 this is because it's defined in "object.d" as an alias for bit.

My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int. Walter can continue this battle by officially defining boolean as an alias for bit as well, and then Matthew will be forced to give his alias for int an awkward name like matthewsbool, or maybe truefalse. Like many people who post to this group, I like the idea of a strongly-typed boolean type. But the language doesn't define one. So I move on. Instead of using bool, I use bit. Bool is just an alias for bit anyway, so why bother with bool? Just use bit, and move on. But what if I absolutely *must* have an int-based bool for performance reasons? Just use int, and move on. What about Matthew's boolean type? I think that this type just creates confusion and inconsistency. Is D going to have *three* boolean types now, bit, bool and boolean? Let's cut this proliferation of boolean types off at the beginning. Just use bit (or if necessary, int). But what about the strongly-typed boolean we want? By all means, keep requesting it. But the language does not define one (yet), so until and unless it does, please don't add to the confusion by trying to define your own. James McComb
Jun 02 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 I've just noticed that the keyword "bool" is accepted by the compiler. Turns


 this is because it's defined in "object.d" as an alias for bit.

My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int.

Your characterisation is, if not entirely satire, disengenuous. D is a language, like C and C++, that provides powerful extensibility mechanisms to allow developers to expand/enhance it at their own discretion. D does not require, any more than C or C++, that every such extension be ratified by the author of the language.
 Walter can continue this battle by officially defining boolean as an
 alias for bit as well, and then Matthew will be forced to give his alias
 for int an awkward name like matthewsbool, or maybe truefalse.

Incorrect. The boolean's I have defined - apart from being stop-gaps to what I still (albeit weakly) hope will be a real one - are defined within modules. Unless Walter does some amazingly prescient word-reserving he cannot stop me or anyone else from defining our own strongly typed boolean.
 Like many people who post to this group, I like the idea of a
 strongly-typed boolean type. But the language doesn't define one. So I
 move on.

I think you've mistaken who's got the dose of stasis here. I resigned myself months ago to there being virtually no hope to the bool issue, and have moved on. Were that not the case, then I wouldn't have written any libraries in that time. As I've said several times now, I can accept Walter saying that it's his language, and he's put his foot down, and bool will never be strongly typed (wrt integral types). That's fine by me. There are things I've done/not done with my libraries despite other people's requests/criticisms. When one is putting in the bulk of the effort, one gets to have the last say. Since he's almost said that many times, I have moved on, and I don't expect it to ever change. However, I do not accept some of the pretty weak arguments to its support - Walter's recent code examples being a great illustration - and until I'm blocked from this NG I'm going to counter such arguments when they're put up. Maybe I've misunderstood what NGs are about, but in my estimation they're not about sucking up opinions you believe to be patently false/absurd just because you (or anyone else) happens to have a high degree of respect for the person offering them. Walter know's in what regard I hold him, both as an engineer and as a person. He was an invaluable reviewer of Imperfect C++, and I've asked him to do the same on my next book. (Never mind the fact that we're going to be writing one together real soon!) But on this issue I believe he's wrong. Should I not say so just because there are several other areas of software engineering where I know his knowledge outstrips mine? You take a group of 100 experienced developers - they'll each know many things the others do not. Which one's get to speak, which one's must be silent? Sounds ludicrous to me. Let me give you another example. Walter and I are both entirely happy with printf(). I can't speak for him, but I know that I'm wrong, and that printf() is bad for D. I only like it, and am comfortable with it, because I have a lot of experience with it and to me - though not to many others, I concede - it is second nature and perfectly safe to use. Any experienced engineer is going to have a fondness for things that are, in an objective estimation, simply wrong/bad/dangerous/setting-a-bad-example. Such is life. I can respect such positions. But I don't respect attempts to justify such partiality. Why not just fess up? It's a simpler existence in the long run. (e.g. it'd have shut me up on this issue months ago. <g>)
 Instead of using bool, I use bit. Bool is just an alias for bit
 anyway, so why bother with bool? Just use bit, and move on. But what if
 I absolutely *must* have an int-based bool for performance reasons? Just
 use int, and move on.

Are you telling me that there's no - that's 0% - advantage to be had by using aliases / weak typedefs?
 What about Matthew's boolean type? I think that this type just creates
 confusion and inconsistency. Is D going to have *three* boolean types
 now, bit, bool and boolean? Let's cut this proliferation of boolean
 types off at the beginning. Just use bit (or if necessary, int).

 But what about the strongly-typed boolean we want? By all means, keep
 requesting it. But the language does not define one (yet), so until and
 unless it does, please don't add to the confusion by trying to define
 your own.

If we are not to define our own type(def)s, then we should be using either Java or .NET. Is that your suggestion? Should the typedef / alias facilities be removed from D? If not, what are they there for? Please provide a "typedef For Dummies" guide, so we can learn how to program appropriately. -- Matthew Wilson Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) STLSoft moderator (http://www.stlsoft.org) "You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael -------------------------------------------------------------------------------
Jun 03 2004
parent reply James McComb <alan jamesmccomb.id.au> writes:
Matthew wrote:

 Your characterisation is, if not entirely satire, disengenuous.

Yes, it was satire. But with a grain of truth, maybe? ;)
 Are you telling me that there's no - that's 0% - advantage to be had by using
 aliases / weak typedefs?

No, I'm saying there's 0% advantage to defining bool or boolean as an alias. You don't actually get anything other than bit or int. If everyone defines their own bool types in their own modules, you don't gain any type safety or usability. The first question a programmer will need to ask when they see a new boolean alias is: "Is it really a bool or really an int?"
 If we are not to define our own type(def)s, then we should be using either Java
 or .NET. Is that your suggestion? Should the typedef / alias facilities be
 removed from D?

We *should* define our own aliases and typedefs. But not for bools. James McComb
Jun 03 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"James McComb" <alan jamesmccomb.id.au> wrote in message
news:c9onle$1p8n$1 digitaldaemon.com...
 Matthew wrote:

  > Your characterisation is, if not entirely satire, disengenuous.

 Yes, it was satire. But with a grain of truth, maybe? ;)

 Are you telling me that there's no - that's 0% - advantage to be had by using
 aliases / weak typedefs?

No, I'm saying there's 0% advantage to defining bool or boolean as an alias. You don't actually get anything other than bit or int.

Ok, so there should be no aliases then? I disagree with that, but haven't the energy to muster argument. Maybe you just mean no third-party bool aliases. That makes more sense, except that they are a placeholder for when/if a real boolean is bestowed upon us.
 If everyone defines their own bool types in their own modules, you don't
 gain any type safety or usability.

This is quite wrong. The boolean type I've defined is a typedef, and therefore there are manifest advantages that they cannot be used for erroneous conversions.
 The first question a programmer will
 need to ask when they see a new boolean alias is: "Is it really a bool
 or really an int?"

Good point.
 If we are not to define our own type(def)s, then we should be using either


 or .NET. Is that your suggestion? Should the typedef / alias facilities be
 removed from D?

We *should* define our own aliases and typedefs. But not for bools.

Ok. I can see the sense in that, except for the optimistic version reason given above. Anyway, I know we're never going to get it, so I'm going to change my libs from boolean to bool, and hang the reduction of robustness. If anyone complains, I shall give them Walter's email address. <G> Boris the Beaten Author: "Imperfect C++", Addison-Wesley, 2004 (http://www.imperfectcplusplus.com) Contributing editor, C/C++ Users Journal (http://www.synesis.com.au/articles.html#columns) Director, Synesis Software (www.synesis.com.au) STLSoft moderator (http://www.stlsoft.org) -----------------------------------------------------
Jun 03 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
James McComb wrote:

 Arcane Jill wrote:
 
 I've just noticed that the keyword "bool" is accepted by the compiler.
 Turns out this is because it's defined in "object.d" as an alias for bit.

My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int.

I doubt that was one of Walter's intentions - I think people complained about the readability of "bit" and requested a more standard word like "bool" or "boolean" or something like that. Since aliases are excellent and providing readability he made an alias.
 Walter can continue this battle by officially defining boolean as an
 alias for bit as well, and then Matthew will be forced to give his alias
 for int an awkward name like matthewsbool, or maybe truefalse.

I don't see this as a battle. The project would never have gotten this far if Walter and/or Matthew behaved like that.
 Like many people who post to this group, I like the idea of a
 strongly-typed boolean type. But the language doesn't define one. So I
 move on. Instead of using bool, I use bit. Bool is just an alias for bit
 anyway, so why bother with bool? Just use bit, and move on. But what if
 I absolutely *must* have an int-based bool for performance reasons? Just
 use int, and move on.

agreed.
 What about Matthew's boolean type? I think that this type just creates
 confusion and inconsistency. Is D going to have *three* boolean types
 now, bit, bool and boolean? Let's cut this proliferation of boolean
 types off at the beginning. Just use bit (or if necessary, int).

Since bool is an alias technically it is not another type. There is still just one boolean type in D (aside from std/recls and std/loader). Personally I use "bool". 99% of std uses "bit". That's ok by me (though I suppose I wish std was 100% consistent).
 But what about the strongly-typed boolean we want? By all means, keep
 requesting it. But the language does not define one (yet), so until and
 unless it does, please don't add to the confusion by trying to define
 your own.

In my daily work with Java and C/C++ I honestly don't remember a time when it mattered. I guess I (and my coworkers) just pass bools around as flags and don't get fancy. So I don't really care if it is strongly typed or not.
 James McComb

Jun 03 2004
prev sibling parent Charlie <Charlie_member pathlink.com> writes:
Well said, I've always used bit ( although I missed where using int gives a gain
in performance , Ill have to try to hunt it down.

C
In article <c9m7qp$15la$1 digitaldaemon.com>, James McComb says...
Arcane Jill wrote:

 I've just noticed that the keyword "bool" is accepted by the compiler. Turns
out
 this is because it's defined in "object.d" as an alias for bit.

My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int. Walter can continue this battle by officially defining boolean as an alias for bit as well, and then Matthew will be forced to give his alias for int an awkward name like matthewsbool, or maybe truefalse. Like many people who post to this group, I like the idea of a strongly-typed boolean type. But the language doesn't define one. So I move on. Instead of using bool, I use bit. Bool is just an alias for bit anyway, so why bother with bool? Just use bit, and move on. But what if I absolutely *must* have an int-based bool for performance reasons? Just use int, and move on. What about Matthew's boolean type? I think that this type just creates confusion and inconsistency. Is D going to have *three* boolean types now, bit, bool and boolean? Let's cut this proliferation of boolean types off at the beginning. Just use bit (or if necessary, int). But what about the strongly-typed boolean we want? By all means, keep requesting it. But the language does not define one (yet), so until and unless it does, please don't add to the confusion by trying to define your own. James McComb

Jun 03 2004
prev sibling parent reply "Bruno A. Costa" <bruno codata.com.br> writes:
Arcane Jill wrote:

 I've just noticed that the keyword "bool" is accepted by the compiler.
 Turns out this is because it's defined in "object.d" as an alias for bit.
 
 At the very least, this enables us to document our code, by having
 appropriate functions return bool instead of bit.
 
 Walter, pending the implementation of a real non-arithmetic bool type, is
 there any chance you could change this alias from bit to int? Then at
 least opEquals() could return a bool. (Or better still, have opEquals()
 return bool).
 

Sorry, but i am not sure if it is a good idea. A bool being aliased to int would permit things like: bool b = 1000; which sounds strange, IMHO. Bruno.
 Arcane Jill

Jun 03 2004
parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <c9nf7e$2vdb$1 digitaldaemon.com>, Bruno A. Costa says...
Arcane Jill wrote:

 I've just noticed that the keyword "bool" is accepted by the compiler.
 Turns out this is because it's defined in "object.d" as an alias for bit.
 
 At the very least, this enables us to document our code, by having
 appropriate functions return bool instead of bit.
 
 Walter, pending the implementation of a real non-arithmetic bool type, is
 there any chance you could change this alias from bit to int? Then at
 least opEquals() could return a bool. (Or better still, have opEquals()
 return bool).
 

Sorry, but i am not sure if it is a good idea. A bool being aliased to int would permit things like: bool b = 1000; which sounds strange, IMHO. Bruno.
 Arcane Jill


false...which in this case is 1 or 0, so the whole !=0 or ==0 thing still works. Everyone: I don't claim to be a "Rocket Scientist" type, but there are a few here whom in my mind, fall into that category, Walter being one (D's truly a "Marvel" to use and write code in)...also Arcane and Matthew come to mind as well. Plus there are many others here in the forum, who've given great ideas and feedback to improve "D", its just takes me a while to remember everyone's name and such. :)) Anywayz, the way I see it, Walter has given us a bool keyword which yes has been alias from a bit, to use within our own code that'll help self-doc when we're using the values as a "flag value." Also we have the two consts "true" and "false" defined in which to test against these boolean flag type values. So, how can it get any simplier? I really fail to see why there are so many threads on this subject, or why the sizeof(bool) really matters. Guess my feet are still planted on the ground, and everyone else is there somewhere flying around me. So, maybe in time I'll understand why this bool thing is such a big deal. :(
Jun 03 2004