www.digitalmars.com         C & C++   DMDScript  

D - To Bool or not to Bool, that is the question...

reply "OddesE" <OddesE_XYZ hotmail.com> writes:
I think bool's are *very* important in a
language. I was very annoyed to find out
that C did not support a bool when I started
programming with it. Pascal supports bool's
and rightly so, and so do C++ and Java.

I also was very annoyed to learn that in C
(typedef'ed) bools usually take up 32 bits.
Thirty-two bits to store a True/False value!

So you can guess that I was pleased to read
that D does not only support bool's (in the
form of bit), but that it stores them in 1 bit!

However this also causes a problem, because
it is not possible to pass bits by reference,
because it is not possible to create a pointer
to a bit. So you cannot do this:


void Function (out bit bMyBit)
{
    if (whatever())
        bMyBit = true;
    else
        bMyBit = false;
}


We need good handling of boolean types.
Please do not leave it to everyone to do:

typedef ubyte bool;

and then pass the bMyBit variable as bool...

The best solution I think would be to create
a new basic type, bool, which would normally
be stored in a bit. When passed as an argument
to a function it would be converted to a byte
sized bool, so you could pass it by reference.
The byte sized bool would be implicitly
converted back to a bit size again when the
function was complete. This is possible because
a bool is guaranteed to only contain the values
0 or 1.

Is this possible? Because I know very little
of compiler technology. But this is what I would
love to see if it were possible.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 14 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:abrtfd$1c9m$1 digitaldaemon.com...

 I think bool's are *very* important in a
 language.


I agree with you.


 The best solution I think would be to create
 a new basic type, bool, which would normally
 be stored in a bit.


Alternatively, references and pointers to bits could be implemented. They
would be special, though. It would require a special pointer representation
using an offset into a byte, or possibly a bit-mask instead. Offsets would
be the best choice, I think, as they would support bit-slices better.
Bit-masks would probably perform better in some situations. A downside of a
special pointer representation is that it cannot be casted to anything else,
so type safety needs to be enforced, and no casts should be allowed.

If performance is the primary concern (and I think it is), a byte-sized
"bool" should be introduced. I don't think it should be stored in a bit, but
the compiler could convert between "bool"s and "bit"s without problems. This
would make "bit" the choice for arrays (bitmaps), and "bool" for almost any
other purpose.

Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this
case, I not sure we need "bit"s - "bool"s would be a better choice for
general use (and also make the compiler simpler), and a solution to bitmaps
could be provided that would extend to larger integrals. What I am
advocating for, is packed arrays instead of "bit". Why should "bit" have
better support than e.g. values 0..7 that also could be benefit greatly from
packed arrays. However, I don't know if packed arrays should be a language
feature or supported by libraries.

Regards,
Martin M. Pedersen
May 14 2002
next sibling parent reply "Matthew Wilson" <mwilson nextgengaming.com> writes:
I agree with Martin. A byte-sized bool is the best.

However, it might be nice to auto-pack a la C's bit fields, eg.

C++:

{

    ...
    int    m_bActive    :    1;
    int    m_bAlive      :    1;

}

D:
{

    ...
    bool    m_bActive;
    bool    m_bAlive;

}

could be packed into the same byte. However, not sure whether this might
lose efficiency, since when assigning from one (that is not in the zeroth
position in the packed byte) a bit-shift would be required.

Overall, then, just living with the wasted 7-bits may be the bet solution,
whilst perhaps allowing explicit bit fields?


"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:abs2p2$1gem$1 digitaldaemon.com...

 Hi,

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:abrtfd$1c9m$1 digitaldaemon.com...

 I think bool's are *very* important in a
 language.


 I agree with you.


 The best solution I think would be to create
 a new basic type, bool, which would normally
 be stored in a bit.


 Alternatively, references and pointers to bits could be implemented. They
 would be special, though. It would require a special pointer


representation

 using an offset into a byte, or possibly a bit-mask instead. Offsets would
 be the best choice, I think, as they would support bit-slices better.
 Bit-masks would probably perform better in some situations. A downside of


a

 special pointer representation is that it cannot be casted to anything


else,

 so type safety needs to be enforced, and no casts should be allowed.

 If performance is the primary concern (and I think it is), a byte-sized
 "bool" should be introduced. I don't think it should be stored in a bit,


but

 the compiler could convert between "bool"s and "bit"s without problems.


This

 would make "bit" the choice for arrays (bitmaps), and "bool" for almost


any

 other purpose.

 Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this
 case, I not sure we need "bit"s - "bool"s would be a better choice for
 general use (and also make the compiler simpler), and a solution to


bitmaps

 could be provided that would extend to larger integrals. What I am
 advocating for, is packed arrays instead of "bit". Why should "bit" have
 better support than e.g. values 0..7 that also could be benefit greatly


from

 packed arrays. However, I don't know if packed arrays should be a language
 feature or supported by libraries.

 Regards,
 Martin M. Pedersen
May 14 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
"Matthew Wilson" <mwilson nextgengaming.com> wrote in message
news:absgk4$1r0c$1 digitaldaemon.com...

 I agree with Martin. A byte-sized bool is the best.

 However, it might be nice to auto-pack a la C's bit fields, eg.

 C++:

 {

     ...
     int    m_bActive    :    1;
     int    m_bAlive      :    1;

 }

 D:
 {

     ...
     bool    m_bActive;
     bool    m_bAlive;

 }


Ranged scalar types would allow the compiler to do this behind the scenes if
it wanted.


 could be packed into the same byte. However, not sure whether this might
 lose efficiency, since when assigning from one (that is not in the zeroth
 position in the packed byte) a bit-shift would be required.


It would definitely lose efficiency (on all architectures I'm aware of).
Not only because of the bit shift (which isn't always required) but because
you can no longer just blindly write into the memory address, you have to
read/modify/write to preserve other adjacent bits.   A processor that didn't
have byte access would have the same problem with bytes; it'd have to use
word reads/writes in combination with shifts and masking.


 Overall, then, just living with the wasted 7-bits may be the bet solution,
 whilst perhaps allowing explicit bit fields?


It's a fairly good solution for speed, *in some cases* (there could be
cases, especially with large arrays, where due to fewer memory cache misses,
it's faster to pack the bits together more)

Reliance on a size of byte isn't good because then the compiler wouldn't be
able to optimize for size if the user wanted to.

I'd hate to see it go the C route and end up with a bool type that we can't
rely on to be any particular size.

Sean
May 15 2002
prev sibling next sibling parent reply "Robert W. Cunningham" <rcunning acm.org> writes:
It looks like we're still in the Land of C, where bool is an integer type.

I believe "bool" should be an object having an implementation that is hidden
from the user.  It would have the values "true" and "false".  The only part of
the D language that would need to understand "bool" would be the logical
operators.

It may be best if D's "bit" were a completely separate thing from a "bool".  A
bit may be properly thought of as the smallest possible integer, and not
necessarily as the keeper of the notions of true and false (though they do map
conveniently).  Conversely, the implementation of "bool" is free to use a bit
as its internal representation, something the user wouldn't (and shouldn't)
know about anyway.  This way, D could offer a very compact implementation of,
say, an array of "bool", without invoking any explicit or implicit notion of
there being a bit vector or an integer involved.  Endianness wouldn't matter,
since neither a single bool nor an array of bool is an integer.

With the bool implementation hidden, passing an array of bool or a single bool
simply won't matter to the user.  Let the compiler handle it.  That is, if you
want bits (say, for mapping to a hardware register), then use bits.  To me,
single bit values in registers and multi-bit values should be treated
identically, as numerical entities, unless they are explicitly converted to
logical entities.  If you want boolean entities (for representing and
aggregating the results of true/false tests), then use bool.  If you need to
map specific numeric integer values to specific meanings, use enums, not bools.

A common weakness of C is its confusing mixing of boolean and integer
operations.  For example, many standard C functions return zero to mean "no
error", yet when used in a logical test, zero means "false" (no bits are
"true", or set), which many users frequently confuse.  Making "bool" a
completely separate thing from integers can help eliminate such confusion in D.

Of course, D will always support the messy C-way of using integers in logical
tests.  If I were the (Non-) Benevolent Dictator For Life, I'd force logical
operators && and || (not to be confused with the numeric parameters to
magnitude comparison tests like ==, < and >=, or the bit-twiddling operations
of |, &, and ^) to only work with "bool", and require explicit casts for
everything else.

I recently came across code like the following:

  if (((x < 4) + (x > 0) + (x != 3))  >= 2) then { // x is sufficiently decided
}

Does this code look "just plain wrong" to anyone other than me?  If comparison
operators returned "bool", and if operators such as addition and magnitude
comparison were not defined for "bool", then code like the above would at least
need explicit casts, making it (IMHO) much clearer.  The line above is a
language hack, and is not a valid logical or mathematical expression.  It has
no place in quality programming.

  int votes = 0;

  if (x<4) votes++;
  if (x > 0) votes++;
  if (x != 3) votes++;
  if (votes >= 2) then { // x is sufficiently decided }

A good C compiler would create the same object code for both forms of the
expression (the first version contains an implicit temporary integer
variable).  Which would you rather debug?

Remember, Boolean Algebra is part of Set Theory, and is not in any way based on
integer algebra.  By definition, booleans are not integers!  They aren't even
single-bit integers.  The confusion between boolean values and bits in the
realm of computer programming occurred only when computers were developed that
used bits (most early electronic computers were pure decimal, with binary
computers following later).  And C, being the language most closely mapped to a
specific computer architecture (the PDP-11), completely failed to make the
distinction.  And we've been living with the consequences ever since.

Does anyone remember how to implement a multi-bit full adder with carry using
only simple gates?  Gates are true boolean devices.  Treating a collection of
booleans as an integer, and performing a mathematical operation upon such
collections, takes some logical gymnastics.  It is non-trivial.  For good
reason:  Booleans aren't integers.

If the notions of single-bit integers and boolean entities are universally and
inseparably intertwined in the minds of all-programmers-who-aren't-me, then
I'll take back my rant, and return quietly to my corner.


-BobC



"Martin M. Pedersen" wrote:


 Hi,

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:abrtfd$1c9m$1 digitaldaemon.com...

 I think bool's are *very* important in a
 language.


 I agree with you.


 The best solution I think would be to create
 a new basic type, bool, which would normally
 be stored in a bit.


 ...
 Perhaps, arrays (bitmaps) is the only reason to support "bit"s. In this
 case, I not sure we need "bit"s - "bool"s would be a better choice for
 general use (and also make the compiler simpler), and a solution to bitmaps
 could be provided that would extend to larger integrals.
 ...
May 14 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
The only good thing I can see of having a separate bool type than bit type
is that you gain the constants true and false, and the optimizer and
function overloading mechanism can differentiate between them, give them
subtly different behavior.  I'm not sure that's a good thing.

Surely in D, true and false are available at very least in some standard
library.  If it is, I can't find it anywhere on the D website.  If not, I
foresee every single programmer coming from Pascal or Java or C++ to provide
conflicting declarations of enum bool { false=0, true=1 };

What happens in D when you do something like this:

enum bool { false=0, true=1 };
enum bool { false=0, true=1 };
enum bool { false=0, true=1 };

?  Is it an error?  Is it ok, since they all match?

Sean

"Robert W. Cunningham" <rcunning acm.org> wrote in message
news:3CE1EEA3.283F59E7 acm.org...

 If the notions of single-bit integers and boolean entities are universally


and

 inseparably intertwined in the minds of all-programmers-who-aren't-me,


then

 I'll take back my rant, and return quietly to my corner.
May 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:abt871$2ggc$1 digitaldaemon.com...


 Surely in D, true and false are available at very least in some standard
 library.  If it is, I can't find it anywhere on the D website.  If not, I


true and false are language keywords. They cannot be redefined.


 What happens in D when you do something like this:

 enum bool { false=0, true=1 };
 enum bool { false=0, true=1 };
 enum bool { false=0, true=1 };

 ?  Is it an error?  Is it ok, since they all match?


I guess no. It'll give a redeclaration error.

By the way, it seems to be an interesting idea, to define bool as:

    enum bool: bit
    {
        false = 0,
        true = 1
    }

Put it somewhere in the library (maybe in some unit that's imported
automaticallly), and remove the true and false keywords from
the language... then, you will be able to cast bool to bit (and thus,
to any integer) implicitly, but an integer would require an explicit
cast to be converted to bool...
May 15 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:abtdm0$2kqq$1 digitaldaemon.com...

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:abt871$2ggc$1 digitaldaemon.com...


 Surely in D, true and false are available at very least in some standard
 library.  If it is, I can't find it anywhere on the D website.  If not,




I

 true and false are language keywords. They cannot be redefined.


 What happens in D when you do something like this:

 enum bool { false=0, true=1 };
 enum bool { false=0, true=1 };
 enum bool { false=0, true=1 };

 ?  Is it an error?  Is it ok, since they all match?


 I guess no. It'll give a redeclaration error.

 By the way, it seems to be an interesting idea, to define bool as:

     enum bool: bit
     {
         false = 0,
         true = 1
     }

 Put it somewhere in the library (maybe in some unit that's imported
 automaticallly), and remove the true and false keywords from
 the language... then, you will be able to cast bool to bit (and thus,
 to any integer) implicitly, but an integer would require an explicit
 cast to be converted to bool...




No, please don't remove the keywords true and false from
the language! They are keywords in C++, Pascal and Java
and for very good reasons! A boolean is a very important
type in programming. Saying it can be easily emulated using
bit's, bytes, words etcetera etcetera is not helping.
We need a bool! Why? Because in C, this is perfectly valid:


typedef unsigned char bool;
#define false 0
#define true 1

// ...

bool bMyBool = 2;
if (bMyBool == false)
    printf ("It is false\n");

else if (bMyBool == true)
    printf ("It is true\n");

else
    printf ("Mmmm...It is neither true or false!!\n");


Conversely, this is also legal:


bool bBool1 = true;
bool bBool2 = 2;

// ...

if (bBool1 == bBool2)
    SaveWorld();
else
    StartNuclearWar();



This sucks!
Please don't make the same mistakes with D.

A bool can only be true or false.
Defining it as an enum of type bit will
ofcourse make sure that there are no problems
like this, but then the problem that we cannot
use it as an out parameter remains. I do not
want to have to do casting just to assign a
byte sized 'bool' to a bit sized 'bool'!

I like the idea of storing them in bits,
but being able to use them as out parameters,
typesafe and without the need for casting,
is much more important to me! In the end I
don't really care that bools take up one byte
instead of one bit, as long as they are typesafe
and well defined. C++, Java and Pascal bool's
were all fine to me.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:abu41b$6g3$1 digitaldaemon.com...


 No, please don't remove the keywords true and false from
 the language! They are keywords in C++, Pascal and Java
 and for very good reasons! A boolean is a very important
 type in programming. Saying it can be easily emulated using
 bit's, bytes, words etcetera etcetera is not helping.
 We need a bool! Why? Because in C, this is perfectly valid:


...

This ain't the case. By inheriting enum from the bit type, the
ONLY two legal values will be true and false.
May 15 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:abu7v0$9t1$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:abu41b$6g3$1 digitaldaemon.com...


 No, please don't remove the keywords true and false from
 the language! They are keywords in C++, Pascal and Java
 and for very good reasons! A boolean is a very important
 type in programming. Saying it can be easily emulated using
 bit's, bytes, words etcetera etcetera is not helping.
 We need a bool! Why? Because in C, this is perfectly valid:


 ...

 This ain't the case. By inheriting enum from the bit type, the
 ONLY two legal values will be true and false.



You are right, but then we still keep the problem
of not being able to use them as out parameters.
Walter, what do true and false do at the moment?
I thought they where already defined as being 0
and 1...

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 15 2002
parent reply "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:abubnh$d8t$1 digitaldaemon.com...

 You are right, but then we still keep the problem
 of not being able to use them as out parameters.
 Walter, what do true and false do at the moment?
 I thought they where already defined as being 0
 and 1...


They're 0 and 1 of type bit.

As this thread shows, unfortunately, there simply is no right way to
implement a boolean type. I remember the same discussion raging with C, with
no consenus resolution.
May 27 2002
parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:actm89$9vi$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:abubnh$d8t$1 digitaldaemon.com...

 You are right, but then we still keep the problem
 of not being able to use them as out parameters.
 Walter, what do true and false do at the moment?
 I thought they where already defined as being 0
 and 1...


 They're 0 and 1 of type bit.

 As this thread shows, unfortunately, there simply is no right way to
 implement a boolean type. I remember the same discussion raging with C,


with

 no consenus resolution.


The problem is not "there isn't a right way to implement booleans", it's
"there isn't an easy way to implement booleans".
Any language I know of has its tricky implementation of booleans. None of
them
do it the right way.
CPUs don't use booleans, so it's a difficult task to give support for it the
right
way.

Ciao.
May 28 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acvd57$177j$1 digitaldaemon.com...


 The problem is not "there isn't a right way to implement booleans", it's
 "there isn't an easy way to implement booleans".
 Any language I know of has its tricky implementation of booleans. None of
 them
 do it the right way.
 CPUs don't use booleans, so it's a difficult task to give support for it


the

 right
 way.


Personally, I'm pretty happy with what we have in D right now.
The only good thing would be to have out/inout bit parameters
(this does NOT imply bit* pointers).
May 28 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
A agree with Pavel, although I wouldn't mind some kind of bit* that let one
address and iterate through individual bits.  ;)  Behind the scenes it's
just a int* and 5 extra address bits which get converted to a bitmask using
1<<bitidx shifts.  The + operator for it would add modulo 32 to the bitidx
and div 32 to the int*.  Then we could point into bit arrays and walk them
just like any other array type.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad01al$26t1$1 digitaldaemon.com...

 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:acvd57$177j$1 digitaldaemon.com...


 The problem is not "there isn't a right way to implement booleans", it's
 "there isn't an easy way to implement booleans".
 Any language I know of has its tricky implementation of booleans. None




of

 them
 do it the right way.
 CPUs don't use booleans, so it's a difficult task to give support for it


 the

 right
 way.


 Personally, I'm pretty happy with what we have in D right now.
 The only good thing would be to have out/inout bit parameters
 (this does NOT imply bit* pointers).
May 28 2002
prev sibling next sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
I agree.
Bool is logically :-) different from a very-small-integer, and therefore it
should be a separate type.
I would even say they should not be implicitly converted into each other.
And of course I would like to a get a pointer and/or a reference to a bool.
Absolutely.
So I think the compiler should not pack this structure, but leave it 2
separate BYTES:
struct A {
bool a, b;
};
int fn()
{
  A s;
  fn2(&s.a);
}
I can accept any implementation solution in the compiler which enables this
syntax.
It's an other question if I want to get a pointer and/or reference to a
very-small-integer, or not.
It seems consistent to have it, but impossible to provide an efficient
implementation.
Well I can live without it.

ps.: Manually typedef-ing bool sucks.

Sandor Hojtsy


"Robert W. Cunningham" <rcunning acm.org> wrote in message
news:3CE1EEA3.283F59E7 acm.org...

 It looks like we're still in the Land of C, where bool is an integer type.



 I believe "bool" should be an object having an implementation that is


hidden

 from the user.  It would have the values "true" and "false".  The only


part of

 the D language that would need to understand "bool" would be the logical
 operators.


[snip]

 It may be best if D's "bit" were a completely separate thing from a


"bool".  A

 bit may be properly thought of as the smallest possible integer, and not
 necessarily as the keeper of the notions of true and false (though they do


map

 conveniently).  Conversely, the implementation of "bool" is free to use a


bit

 as its internal representation, something the user wouldn't (and


shouldn't)

 know about anyway.  This way, D could offer a very compact implementation


of,

 say, an array of "bool", without invoking any explicit or implicit notion


of

 there being a bit vector or an integer involved.  Endianness wouldn't


matter,

 since neither a single bool nor an array of bool is an integer.


[snip]

 With the bool implementation hidden, passing an array of bool or a single


bool

 simply won't matter to the user.  Let the compiler handle it.  That is, if


you

 want bits (say, for mapping to a hardware register), then use bits.  To


me,

 single bit values in registers and multi-bit values should be treated
 identically, as numerical entities, unless they are explicitly converted


to

 logical entities.  If you want boolean entities (for representing and
 aggregating the results of true/false tests), then use bool.  If you need


to

 map specific numeric integer values to specific meanings, use enums, not


bools.
[snip]

 A common weakness of C is its confusing mixing of boolean and integer
 operations.  For example, many standard C functions return zero to mean


"no

 error", yet when used in a logical test, zero means "false" (no bits are
 "true", or set), which many users frequently confuse.  Making "bool" a
 completely separate thing from integers can help eliminate such confusion


in D.
[snip]

 Of course, D will always support the messy C-way of using integers in


logical

 tests.  If I were the (Non-) Benevolent Dictator For Life, I'd force


logical

 operators && and || (not to be confused with the numeric parameters to
 magnitude comparison tests like ==, < and >=, or the bit-twiddling


operations

 of |, &, and ^) to only work with "bool", and require explicit casts for
 everything else.


[snip]

 Remember, Boolean Algebra is part of Set Theory, and is not in any way


based on

 integer algebra.  By definition, booleans are not integers!  They aren't


even

 single-bit integers.  The confusion between boolean values and bits in the
 realm of computer programming occurred only when computers were developed


that

 used bits (most early electronic computers were pure decimal, with binary
 computers following later).  And C, being the language most closely mapped


to a

 specific computer architecture (the PDP-11), completely failed to make the
May 15 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Robert W. Cunningham" <rcunning acm.org> wrote in message
news:3CE1EEA3.283F59E7 acm.org...


 I recently came across code like the following:

   if (((x < 4) + (x > 0) + (x != 3))  >= 2) then { // x is sufficiently


decided

 }


I write such things myself. =)
That's why C (and D) rulez!
May 15 2002
prev sibling parent Andy Walker <Andy_member pathlink.com> writes:
In article <3CE1EEA3.283F59E7 acm.org>, Robert W. Cunningham says...

Remember, Boolean Algebra is part of Set Theory, and is not in any way based on
integer algebra.  By definition, booleans are not integers!  They aren't even
single-bit integers.  The confusion between boolean values and bits in the
realm of computer programming occurred only when computers were developed that
used bits (most early electronic computers were pure decimal, with binary
computers following later).  And C, being the language most closely mapped to a
specific computer architecture (the PDP-11), completely failed to make the
distinction.  And we've been living with the consequences ever since.


Um ... my recollection is that almost immediately all computers went to binary,
for very good reasons.  

I have never spoken to Kernighan or Ritchie, but my strong suspicion is that the
confusion was intentional.  The goal was a compact and powerful language.  I
think they succeeded.  From my point of view, the approach was an idea whose
time had come, and has now passed.

In every COBOL shop where I have ever worked, you could get a boolean packing
and unpacking subroutine.  In every on of those shops, this was strictly against
company policy.  No one would openly admit knowing about it or using it.
Documentation did not exist.  Everyone would tell you how to do it, behind
closed doors.   


Does anyone remember how to implement a multi-bit full adder with carry using
only simple gates? 


Do I lose all credibility if I admit this? 


If the notions of single-bit integers and boolean entities are universally and
inseparably intertwined in the minds of all-programmers-who-aren't-me, then
I'll take back my rant, and return quietly to my corner.


Single-bit integers and boolean entities are NOT inseparably intertwined in my
mind.  


-BobC
May 27 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Martin M. Pedersen" wrote:


 Alternatively, references and pointers to bits could be implemented. They
 would be special, though. It would require a special pointer representation
 using an offset into a byte, or possibly a bit-mask instead. Offsets would
 be the best choice, I think, as they would support bit-slices better.
 Bit-masks would probably perform better in some situations. A downside of a
 special pointer representation is that it cannot be casted to anything else,
 so type safety needs to be enforced, and no casts should be allowed.


Yes, pointers-to-bool should be implemented.  After all, we have
pointers-to-functions, delegates, etc.  We cannot assume that all pointers are
just simple address values.


 If performance is the primary concern (and I think it is), a byte-sized
 "bool" should be introduced. I don't think it should be stored in a bit, but
 the compiler could convert between "bool"s and "bit"s without problems. This
 would make "bit" the choice for arrays (bitmaps), and "bool" for almost any
 other purpose.


If you want a byte-sized variable, use 'byte' or 'ubyte'.



Really, I think that 'bool' should be a logical type, not a mathematical one.
We can have two 1-bit types:

* bool: returned by comparisons, required by for/while/if tests, NOT a
mathematical type
* bit: a mathematical type

Both can be bit-packed into arrays, and you should be able to have pointers to
them.  Internally, bool's and bit's are identical, but we separate them in
syntax so that we can have more explicit typechecking.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
May 15 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE26570.1912AF41 deming-os.org...


 * bool: returned by comparisons, required by for/while/if tests, NOT a
 mathematical type
 * bit: a mathematical type

 Both can be bit-packed into arrays, and you should be able to have


pointers to

 them.  Internally, bool's and bit's are identical, but we separate them in
 syntax so that we can have more explicit typechecking.


Much like char and byte are the same, but are considered different
by the compiler... I'm pretty happy without it, but I wouldn't mind
to have it, as well. =)
May 15 2002
prev sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE26570.1912AF41 deming-os.org...

 "Martin M. Pedersen" wrote:


 Alternatively, references and pointers to bits could be implemented.




They

 would be special, though. It would require a special pointer




representation

 using an offset into a byte, or possibly a bit-mask instead. Offsets




would

 be the best choice, I think, as they would support bit-slices better.
 Bit-masks would probably perform better in some situations. A downside




of a

 special pointer representation is that it cannot be casted to anything




else,

 so type safety needs to be enforced, and no casts should be allowed.


 Yes, pointers-to-bool should be implemented.  After all, we have
 pointers-to-functions, delegates, etc.  We cannot assume that all pointers


are

 just simple address values.


 If performance is the primary concern (and I think it is), a byte-sized
 "bool" should be introduced. I don't think it should be stored in a bit,




but

 the compiler could convert between "bool"s and "bit"s without problems.




This

 would make "bit" the choice for arrays (bitmaps), and "bool" for almost




any

 other purpose.


 If you want a byte-sized variable, use 'byte' or 'ubyte'.



 Really, I think that 'bool' should be a logical type, not a mathematical


one.

 We can have two 1-bit types:

 * bool: returned by comparisons, required by for/while/if tests, NOT a
 mathematical type
 * bit: a mathematical type

 Both can be bit-packed into arrays, and you should be able to have


pointers to

 them.  Internally, bool's and bit's are identical, but we separate them in
 syntax so that we can have more explicit typechecking.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]




Using ubyte or byte as booleans is not typesafe. The problem
with using bit as a boolean is that you cannot do this:


void performSomeTests (out bit a, b, c)
{
    a = foo();
    b = bar();
    c = baz();
}

bit a, b, c;
performSomeTests (a, b, c);


Because this would require pointer to bits, which
are not implemented. You could solve this problem
in two ways:

1)  Implement pointers to bits.
2)  Create a byte sized boolean type.

Both ensure type safety, so a bool / bit cannot
become 2, 3, etc, but only 0 (false) or 1 (true).
However if bool is bit sized this will cause
problems interfacing to other languages, the
most of which will use byte-sized booleans.

I would like it the most to keep bit the way
it is and define three new types, bool, bool16
and bool32, of 8, 16 and 32 bits respectively.
Use bool as the primary boolean type, make them
all typesafe so they can only assume the values
false and true and then make them implicitly
convertible to one and another, as well as to
bit. bool16 and bool32 can be used to interface
with C code in a typesafe manner, while bit
can be used in places where size really matters,
such as very large arrays of boolean values.

If this is to much to ask I would settle for
a simple byte sized bool C++ style, and live
with the casting needed to convert 16 or 32 bit
booleans from C code to bool.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 15 2002
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I think that sometimes a byte-sized (or even 32-bit sized) bool can be
faster than a bit-sized bool.  That's because a store is almost universally
faster than a read/modify/write operation.

However if a bit-sized bool isn't available, people use bitfields or (egad!)
manual int flags fields and #define's and lots of flags &= ~(TYPE_A|TYPE_B)
type gobbledygook that the compiler can deal with much easier than humans
can.

So I'm glad there's a bit type, and that it packs into bytes nicely.
Hopefully the compiler will try to group all the bit type variables together
when possible, to save space.  Saved space means fewer cache misses, which
means better performance too!

But I think it's vital to be able to deal with all types as parameters, to
have pointers to them, etc.

Did anyone think having pointers to bits be extra-special pointers with a
combined bit index was a good idea?  If not, why not?

Did anyone think having the compiler insert special byte or word-sized
"conversion buffers" that would facilitate their use as reference parameters
was a good idea?  If not, why not?

Sean

"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:abrtfd$1c9m$1 digitaldaemon.com...

 I think bool's are *very* important in a
 language. I was very annoyed to find out
 that C did not support a bool when I started
 programming with it. Pascal supports bool's
 and rightly so, and so do C++ and Java.

 I also was very annoyed to learn that in C
 (typedef'ed) bools usually take up 32 bits.
 Thirty-two bits to store a True/False value!

 So you can guess that I was pleased to read
 that D does not only support bool's (in the
 form of bit), but that it stores them in 1 bit!

 However this also causes a problem, because
 it is not possible to pass bits by reference,
 because it is not possible to create a pointer
 to a bit. So you cannot do this:


 void Function (out bit bMyBit)
 {
     if (whatever())
         bMyBit = true;
     else
         bMyBit = false;
 }


 We need good handling of boolean types.
 Please do not leave it to everyone to do:

 typedef ubyte bool;

 and then pass the bMyBit variable as bool...

 The best solution I think would be to create
 a new basic type, bool, which would normally
 be stored in a bit. When passed as an argument
 to a function it would be converted to a byte
 sized bool, so you could pass it by reference.
 The byte sized bool would be implicitly
 converted back to a bit size again when the
 function was complete. This is possible because
 a bool is guaranteed to only contain the values
 0 or 1.

 Is this possible? Because I know very little
 of compiler technology. But this is what I would
 love to see if it were possible.
May 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:abt77j$2fh9$1 digitaldaemon.com...


 Did anyone think having pointers to bits be extra-special pointers with a
 combined bit index was a good idea?  If not, why not?


Yes, exactly. As long as we can have bit*, I don't care about all
the bool stuff. Especially since "bool" is one character longer
than "bit". =)
May 15 2002
parent reply Burton Radons <loth users.sourceforge.net> writes:
On Wed, 15 May 2002 14:42:29 +0400, "Pavel Minayev" <evilone omen.ru>
wrote:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:abt77j$2fh9$1 digitaldaemon.com...


 Did anyone think having pointers to bits be extra-special pointers with a
 combined bit index was a good idea?  If not, why not?


Yes, exactly. As long as we can have bit*, I don't care about all
the bool stuff. Especially since "bool" is one character longer
than "bit". =)


Err, can someone produce a valid example of where you need a bit
pointer or reference that cannot be refactored to avoid it?

I have hit this problem with bit three times already while writing D
code.  Each time I changed the code and the problem disappeared...
after awhile, I won't write such code any more.

Oh, and has anyone found an example of where Quake 3's lack of
security in the DLLs has been exploited?  One example is all I've
asked for.  I mean, I was expecting at least one wanker to have put up
a malicious bot, then I could point out how quickly the problem was
found and he was ostracized.  It's a waste of a good counterpoint.
May 15 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:a0p4euovk8lcshb5kk5r7t5l7qdmjnv380 4ax.com...

 On Wed, 15 May 2002 14:42:29 +0400, "Pavel Minayev" <evilone omen.ru>
 wrote:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:abt77j$2fh9$1 digitaldaemon.com...


 Did anyone think having pointers to bits be extra-special pointers with






a

 combined bit index was a good idea?  If not, why not?


Yes, exactly. As long as we can have bit*, I don't care about all
the bool stuff. Especially since "bool" is one character longer
than "bit". =)




bit* seems like a good idea too, but I don't know how difficult
it is to implement. I could live without bit pointers, but not
without good bool support...



 Err, can someone produce a valid example of where you need a bit
 pointer or reference that cannot be refactored to avoid it?


void performSomeTests (out bit a, b, c)
{
    a = foo();
    b = bar();
    c = baz();
}

bit a, b, c;
performSomeTests (a, b, c);


It seems to me that being able to return multiple booleans
from a function is something done quitte often.

This example is lame ofcourse, but if the function wouldn't
return void but some number or whatever I think the problem
would be more clear.

Come to think of it, when programming COM you normally
always return a HRESULT, so you can forget about returning
bits at all!

I like the idea of boolean values being stored in bits a
lot, but this is just to high a price to pay!


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 15 2002