"BenjiSmith" <BenjiSmith_member@pathlink.com> wrote in message news:bgmpoe$2ph4$1@digitaldaemon.com...
> I think that a 'bit' gives the impression that it will always be
implemented as
> one element of an eight-element byte. That's the impression that I get
from
> using a 'bit'. I don't know if that's how it's implemented in DMD, but
that's
> how I think of it: as a tiny unit of memory.

'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the rest of the byte is unused.

> Now, a 'boolean' is not a unit of memory as all. It's a semantic term
given to a
> true/false condition. I don't care how a boolean is implemented, as long
as it
> has two-and-only-two values: true and false, and as long as it provides me
a
> mechanism for flipping between the two values.

'bit' does that.

> If you're a compiler vendor (and you are), I don't care whether you
implement
> the boolean primitive type as a bit or as an 8-bit type, if that makes addressing and dereferencing more efficient. Let the compiler do whatever
it
> wants with boolean types as long as I can get sizeof(boolean) to know how
many
> bits (or bytes) are taken up by the type. However, if I call sizeof(bit),
it
> should be exactly the same on every platform (.125).

'bit' does that, too. bit.size will give (1), because unless it is an array of bits, it is put into a byte.

> I don't know if anybody else is on the same page as me, but these are the reasons that I'd like to have a boolean type instead of just a bit type.
Of
> course, I'd like to have _both_ bits and booleans (please just don't call
it
> 'bool'), since bits (and bit arrays) could be useful for their own
purposes. But
> I'd prefer to keep my true/false values in a boolean than in a bit.

I just fail to see what improvement boolean has over bit. Also, what's wrong with 'bool'? It fits with the C'ish convention of using 'int' instead of 'integer', 'float' instead of 'floatingpointreal', etc.

On Mon, 4 Aug 2003 18:34:51 -0700 (08/05/03 11:34:51)
, Walter <walter@digitalmars.com> wrote:

>
> "BenjiSmith" <BenjiSmith_member@pathlink.com> wrote in message
> news:bgmpoe$2ph4$1@digitaldaemon.com...
>> I think that a 'bit' gives the impression that it will always be
> implemented as
>> one element of an eight-element byte. That's the impression that I get
> from
>> using a 'bit'. I don't know if that's how it's implemented in DMD, but
> that's
>> how I think of it: as a tiny unit of memory.
>
> 'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the
> rest of the byte is unused.
>
>> Now, a 'boolean' is not a unit of memory as all. It's a semantic term
> given to a
>> true/false condition. I don't care how a boolean is implemented, as long
> as it
>> has two-and-only-two values: true and false, and as long as it provides me
> a
>> mechanism for flipping between the two values.
>
> 'bit' does that.
>
>> If you're a compiler vendor (and you are), I don't care whether you
> implement
>> the boolean primitive type as a bit or as an 8-bit type, if that makes
>> addressing and dereferencing more efficient. Let the compiler do whatever
> it
>> wants with boolean types as long as I can get sizeof(boolean) to know how
> many
>> bits (or bytes) are taken up by the type. However, if I call sizeof(bit) ,
> it
>> should be exactly the same on every platform (.125).
>
> 'bit' does that, too. bit.size will give (1), because unless it is an array
> of bits, it is put into a byte.
>
>> I don't know if anybody else is on the same page as me, but these are the
>> reasons that I'd like to have a boolean type instead of just a bit type.
> Of
>> course, I'd like to have _both_ bits and booleans (please just don't call
> it
>> 'bool'), since bits (and bit arrays) could be useful for their own
> purposes. But
>> I'd prefer to keep my true/false values in a boolean than in a bit.
>
> I just fail to see what improvement boolean has over bit. Also, what's wrong
> with 'bool'? It fits with the C'ish convention of using 'int' instead of
> 'integer', 'float' instead of 'floatingpointreal', etc.

Its a conceptual thing mainly. A 'bool' is a STATE but a 'bit' holds a data value. A 'bit' must be mapped to a RAM location but a 'bool' doesn't (I'm not talking about implementatin here - just logical/conceptual stuff).

Conceptually, you can do arithmetic with bits but it doesn't make sense to add up three 'bools', for example.

When it comes to implementing a bool, you would probably wise to choose a data storage element that is fast - such as an int. However, you might serious consider disallowing arithmetic functionality, include comparisions to numeric values. It doesn't make much sense if test if a 'bool' is larger than 5, for example.

As you mention above, a 'bit' can be used to implement a 'bool'. However, a 'bit' has more functionality behind it than a 'bool' needs or even wants. -- Derek

Walter wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bgmfml$2fr1$1@digitaldaemon.com...
> 
>>>I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
>>>there is the implication that there is none of this tri-state confusion
>>>nonsense we find in C, but others obviously don't see it that way.
> 
> "bool" is
> 
>>>used in C and C++.
>>
>>"boolean" describes its semantics without bringing in either unfortunate
>>comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
> 
> 
> What wrong impression does bit give? I'm a bit (!) flummoxed as to why
> people find bit so distasteful.

It gives the impression that it has "bit" semantics!  A bit is an integer in the range [0, 1]:

   bit a;

   a = 0.1; /* results in 0 */
   a = 1.1; /* results in 1 */
   a = 2; /* results in 0 */
   a = 3; /* results in 1 */

A boolean, on the other hand, has no arithmetic, different casting semantics, no defined integral value in memory, and different purposes.  It has an identical value range, but so do ubyte and char.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgn2pr$bk$1@digitaldaemon.com...
> Walter wrote:
>
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgmfml$2fr1$1@digitaldaemon.com...
> >
> >>>I've put a bool alias for bit in 0.69. I found "bit" to be appealing,
as
> >>>there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way.
> >
> > "bool" is
> >
> >>>used in C and C++.
> >>
> >>"boolean" describes its semantics without bringing in either unfortunate
> >>comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
> >
> >
> > What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.
>
> It gives the impression that it has "bit" semantics!  A bit is an integer in the range [0, 1]:
>
>     bit a;
>
>     a = 0.1; /* results in 0 */
>     a = 1.1; /* results in 1 */
>     a = 2; /* results in 0 */
>     a = 3; /* results in 1 */
>
> A boolean, on the other hand, has no arithmetic, different casting
> semantics, no defined integral value in memory, and different purposes.
>   It has an identical value range, but so do ubyte and char.

Just make:

1. bit implicitly convertible to 0 or 1.
2. casting from x to a bit be defined by:
    cast(bit)x => (x != 0)

fulfilling both roles neatly. (Your third and fourth examples would set a to
true.)

In article <bgn1bu$30od$1@digitaldaemon.com>, Walter says...
>
>> how I think of it: as a tiny unit of memory.
>
>'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and the rest of the byte is unused.

sorry, to embedded folks that's a little confusing. we want a bit to be one part of a register or memory location which may be combined together in contiguous but odd or even sizes (the hardware guys never like to waste bits by padding out) to control all sorts of stuff.

0         5            12                       31
| field_1 | field_2    |        field_3         |

If D is supposed to be a systems programming language than it shouldn't confuse the hardware engineers who create the FPGAs which in turn are manipulated by the embedded SW folks.

after a quick google search found this interesting piece on C and Ada bit fields representation:

http://www.ankh-morpork.com/Simon/adabook/c3_7.htm

> >
> > A boolean, on the other hand, has no arithmetic, different casting
> > semantics, no defined integral value in memory, and different purposes.
> >   It has an identical value range, but so do ubyte and char.
>
> Just make:
>
> 1. bit implicitly convertible to 0 or 1.
> 2. casting from x to a bit be defined by:
>     cast(bit)x => (x != 0)
>

but what about the other way ?
    int i;
    cast(boolean)i  (implies i!=0)
    cast(bit)i   (implies i&1, given that cast(byte)i is i&0xFF)

and here lies the reason for (and difference of) boolean and bit.

"Mark T" <Mark_member@pathlink.com> wrote in message news:bgo4e1$111h$1@digitaldaemon.com...
> In article <bgn1bu$30od$1@digitaldaemon.com>, Walter says...
> >
> >> how I think of it: as a tiny unit of memory.
> >
> >'bit' is one bit, although it may be in a byte as the (lonely) bit 0 and
the
> >rest of the byte is unused.
>
> sorry, to embedded folks that's a little confusing. we want a bit to be
one part
> of a register or memory location which may be combined together in
contiguous
> but odd or even sizes (the hardware guys never like to waste bits by
padding
> out) to control all sorts of stuff.
>
> 0         5            12                       31
> | field_1 | field_2    |        field_3         |
>
> If D is supposed to be a systems programming language than it shouldn't
confuse
> the hardware engineers who create the FPGAs which in turn are manipulated
by the
> embedded SW folks.

I've actually done code dealing with such issues (and I've even written FPGA design tools), and I find it works best to simply write the shift and mask operations custom to the job.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bgoefc$1b9o$1@digitaldaemon.com...
> > >
> > > A boolean, on the other hand, has no arithmetic, different casting semantics, no defined integral value in memory, and different
purposes.
> > >   It has an identical value range, but so do ubyte and char.
> > Just make:
> > 1. bit implicitly convertible to 0 or 1.
> > 2. casting from x to a bit be defined by:
> >     cast(bit)x => (x != 0)
> but what about the other way ?
>     int i;
>     cast(boolean)i  (implies i!=0)
>     cast(bit)i   (implies i&1, given that cast(byte)i is i&0xFF)
> and here lies the reason for (and difference of) boolean and bit.

Ok, I see what you are driving at. But the cast(bit)i being (i&1) is not
necessary if the former is supported.

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bgn2pr$bk$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>
>>>"Burton Radons" <loth@users.sourceforge.net> wrote in message
>>>news:bgmfml$2fr1$1@digitaldaemon.com...
>>>
>>>
>>>>>I've put a bool alias for bit in 0.69. I found "bit" to be appealing,
> 
> as
> 
>>>>>there is the implication that there is none of this tri-state confusion
>>>>>nonsense we find in C, but others obviously don't see it that way.
>>>
>>>"bool" is
>>>
>>>
>>>>>used in C and C++.
>>>>
>>>>"boolean" describes its semantics without bringing in either unfortunate
>>>>comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
>>>
>>>
>>>What wrong impression does bit give? I'm a bit (!) flummoxed as to why
>>>people find bit so distasteful.
>>
>>It gives the impression that it has "bit" semantics!  A bit is an
>>integer in the range [0, 1]:
>>
>>    bit a;
>>
>>    a = 0.1; /* results in 0 */
>>    a = 1.1; /* results in 1 */
>>    a = 2; /* results in 0 */
>>    a = 3; /* results in 1 */
>>
>>A boolean, on the other hand, has no arithmetic, different casting
>>semantics, no defined integral value in memory, and different purposes.
>>  It has an identical value range, but so do ubyte and char.
> 
> 
> Just make:
> 
> 1. bit implicitly convertible to 0 or 1.
> 2. casting from x to a bit be defined by:
>     cast(bit)x => (x != 0)

Which is boolean semantics, not bit.

> fulfilling both roles neatly. (Your third and fourth examples would set a to
> true.)

That it can be forced to behave similar to a bit using a lot of casting and support code doesn't change the fact that it's NOT A BIT.