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.


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


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.


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


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


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 "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* -


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


<snip>

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




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.


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


issue, in

 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.




 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


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.


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


other,

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


I'm

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


all our

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


experienced

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


say

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


Languages that don't do implicit conversions are relative failures, and I've
used some of those languages and know why. They're a pain to use. They
require lots of casting to get real work done, and peppering one's routine
code with casts is LESS typesafe than well understood implicit type
conversions. Furthermore, complex C/C++ expressions will exhibit subtle
changes in behavior when converted to D. This can be a disaster if it is,
for example, crypto code.

Consider, for example, the following code:

class A { void foo() { } }
void test() { A a; a.foo(); }

Which would work in C++, but fails in D. This regularly trips up people
coming to D from C++. Fortunately, the code fails predictably in a manner
that pinpoints the problem, the solution is explained, and one goes on. This
will not happen if implicit conversion rules are changed - the program will
appear to work, but the result of the expression will be subtly different.
Even worse, it will compute the same result with some values of the
operands, and different results with others.

So, one general principle I try to follow is that if D changes the rules, if
one tries it the C++ way, one gets an obvious failure rather than a subtle,
erratic one. This effectively rules out changing things like implicit
conversion rules and operator precedence.


     - make typedefs strong - which D has done. Hurrah!
     - stop bool being an integral type - which Walter's ruled out
     - make an ABI - which has so far been ignored


The ABI will happen, it's just premature.


     - has it got libraries - which I would suggest more of us would be


doing if

 there was not still such fertile ground for language debates at a very
 low/fundamental level


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


     - give me decent templates - which we're certainly working towards

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


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


 issue, in

 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.




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


 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.


 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


 other,

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


 I'm

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


 all our

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


 experienced

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


 say

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


 Languages that don't do implicit conversions are relative failures, and I've
 used some of those languages and know why. They're a pain to use. They
 require lots of casting to get real work done, and peppering one's routine
 code with casts is LESS typesafe than well understood implicit type
 conversions. Furthermore, complex C/C++ expressions will exhibit subtle
 changes in behavior when converted to D. This can be a disaster if it is,
 for example, crypto code.


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


 doing if

 there was not still such fertile ground for language debates at a very
 low/fundamental level


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


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


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.


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


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.


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.


 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?


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_


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


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,


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.


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




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.


That's true for implicit narrowing conversions.


 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.


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


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.


All right.


 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?


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


array of

 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


 array of

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


Bit arrays are particularly useful for for sets.

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




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


 Bit arrays are particularly useful for for sets.

 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 
  


Dam Matthew, half the time I read you, I have to go for the dictionary.  
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


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


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


 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.


 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


 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.


 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.


 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?


 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_


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


 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,


 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.


 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




 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.


 That's true for implicit narrowing conversions.


 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.


 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


 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.


 All right.


 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?


 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?
  


The efficiency comes with caching and memory copying when you have more 
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_


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


...

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,


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.


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


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)


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




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!"


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




 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!"


 
 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),


 "uglified"? One person's "ugly" is another person "documentation" ;-)


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
        




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!"
      


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.

  



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




 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!"


 
 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




 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!"


 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


meaningful

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


library

 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




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



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




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 :)


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


mentioned

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




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.


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




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.


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




Arcane: I agree with your thoughts, a bool should never be anything but true or
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