digitalmars.D

Some problems and inconsistencies with bits.

(1). The expression:

       (a == b)


yields type int, not type bit. Indeed, the statement:

       bit b = (a == b);


is rejected by the compiler, and must be transofmed into:

       bit b = cast(bit)(a==b);


in order to compile.

(2) (BUG). The statements:

       bit b = true;
       uint i = -b;


leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.

(3) The declaration:

       bit[256] b;


creates an array of 256 bytes, not 32 bytes (which would be 256 bits in total). 

Arcane Jill

May 24 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Yep, it stinks. A proper boolean type, that's not implicitly convertible to any
other type, is required. All (sub-)expressions should be of boolean type.


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8s7tg$1b7s$1 digitaldaemon.com...
 Some problems and inconsistencies with bits.

 (1). The expression:

       (a == b)


 yields type int, not type bit. Indeed, the statement:

       bit b = (a == b);


 is rejected by the compiler, and must be transofmed into:

       bit b = cast(bit)(a==b);


 in order to compile.

 (2) (BUG). The statements:

       bit b = true;
       uint i = -b;


 leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.

 (3) The declaration:

       bit[256] b;


 creates an array of 256 bytes, not 32 bytes (which would be 256 bits in total).

 Arcane Jill

May 24 2004

Juan C <Juan_member pathlink.com> writes:

Yep, it stinks. A proper boolean type, that's not implicitly convertible to any
other type, is required. All (sub-)expressions should be of boolean type.


Not implicitly convertible _from_ either.

May 24 2004

"Ben Hinkle" <bhinkle mathworks.com> writes:

I can't reproduce items 1 or 3. Here's the code I ran:

int main() {
  int a1,a2;
  a1 = 3;
  a2 = 4;
  bit b = (a1 == a2);
  printf("%d\n",b);

  bit b2 = true;
  uint i = -b2;
  printf("%u\n",i);

  bit[256] b3;
  printf("%d\n",b3.sizeof);

  return 0;
}

results in

0
255
32

Personally item 2 seems like an odd programming practice so the current
behavior doesn't bother me.

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8s7tg$1b7s$1 digitaldaemon.com...
 Some problems and inconsistencies with bits.

 (1). The expression:

       (a == b)


 yields type int, not type bit. Indeed, the statement:

       bit b = (a == b);


 is rejected by the compiler, and must be transofmed into:

       bit b = cast(bit)(a==b);


 in order to compile.

 (2) (BUG). The statements:

       bit b = true;
       uint i = -b;


 leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.

 (3) The declaration:

       bit[256] b;


 creates an array of 256 bytes, not 32 bytes (which would be 256 bits in


 Arcane Jill

May 24 2004

Arcane Jill <Arcane_member pathlink.com> writes:

In article <c8t5d2$2ngh$1 digitaldaemon.com>, Ben Hinkle says...
I can't reproduce items 1 or 3. Here's the code I ran:

int main() {
  int a1,a2;
  a1 = 3;
  a2 = 4;
  bit b = (a1 == a2);
  printf("%d\n",b);


It appears that ints behave differently from objects in this regard. The
following (very similar) code fails to compile:

class A {}

int main() {
A a1,a2;
a1 = new A;
a2 = new A;
bit b = (a1 == a2);

return 0;
}

The error message is "cannot implicitly convert int to bit". Curious.


  bit[256] b3;
  printf("%d\n",b3.sizeof);


I was wrong. False alarm. My error was due to the fact that MS visual studio
reports b3 as being of type unsigned char[256] when you use that to step through
the code. But upon investigation, visual studio is simply wrong.

I must assume therefore that the debug information in the .obj file is somehow
storing the type incorrectly - which does not change the execution of the
program one iota.



Personally item 2 seems like an odd programming practice so the current
behavior doesn't bother me.


I noticed it because I encountered it. It's a normal thing to do in a subtract
routine where you have to propogate a carry bit (note: bit) to the next uint of
a multiprecision integer.

Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false. In this scenario, bits could be
auto-promoted to int or uint (since those would be widening conversions) but
bool could not (because logical types should not auto-convert to arithmetic
types).

May 24 2004

Juan C <Juan_member pathlink.com> writes:

Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false. In this scenario, bits could be
auto-promoted to int or uint (since those would be widening conversions) but
bool could not (because logical types should not auto-convert to arithmetic
types).


Yay, another vote!

May 24 2004

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8t9sf$2uua$1 digitaldaemon.com...
 In article <c8t5d2$2ngh$1 digitaldaemon.com>, Ben Hinkle says...
I can't reproduce items 1 or 3. Here's the code I ran:

int main() {
  int a1,a2;
  a1 = 3;
  a2 = 4;
  bit b = (a1 == a2);
  printf("%d\n",b);


 It appears that ints behave differently from objects in this regard. The
 following (very similar) code fails to compile:

 class A {}

 int main() {
 A a1,a2;
 a1 = new A;
 a2 = new A;
 bit b = (a1 == a2);

 return 0;
 }

 The error message is "cannot implicitly convert int to bit". Curious.


Yes, that is curious. Also note
  bit b = (a1 is a2);
works.

May 24 2004

Derek Parnell <derek psych.ward> writes:

On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:

[snip]
 
 Personally, I would favor two distinct types: bit and bool, with bit being
 considered an arithmetic type (like a one bit wide unsigned integer), and bool
 able only to take values true and false. In this scenario, bits could be
 auto-promoted to int or uint (since those would be widening conversions) but
 bool could not (because logical types should not auto-convert to arithmetic
 types).


100% agree. 

'bit' is a very small unsigned integer whose value is in the range 0 (zero)
to 1 (one). And I presume 'sizeof(bit)' should return the number of bytes
the the implementation uses. 

'bool' is NOT an integer. It can only have either of two values - TRUE or
FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0
for FALSE and 1 for TRUE.

-- 
Derek
25/May/04 8:36:43 AM

May 24 2004

"Bruno A. Costa" <bruno codata.com.br> writes:

Derek Parnell wrote:

 On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:
 
 [snip]
  
 Personally, I would favor two distinct types: bit and bool, with bit
 being considered an arithmetic type (like a one bit wide unsigned
 integer), and bool able only to take values true and false. In this
 scenario, bits could be auto-promoted to int or uint (since those would
 be widening conversions) but bool could not (because logical types should
 not auto-convert to arithmetic types).


 100% agree.
 
 'bit' is a very small unsigned integer whose value is in the range 0
 (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number of
 bytes the the implementation uses.
 
 'bool' is NOT an integer. It can only have either of two values - TRUE or
 FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0
 for FALSE and 1 for TRUE.
 


This is good. I vote for a bool type. Or at least an implicit cast
from boolean expressions to bit.

Bruno.

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Bruno A. Costa" <bruno codata.com.br> wrote in message
news:c8vc34$k50$1 digitaldaemon.com...
 Derek Parnell wrote:

 On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:

 [snip]

 Personally, I would favor two distinct types: bit and bool, with bit
 being considered an arithmetic type (like a one bit wide unsigned
 integer), and bool able only to take values true and false. In this
 scenario, bits could be auto-promoted to int or uint (since those would
 be widening conversions) but bool could not (because logical types should
 not auto-convert to arithmetic types).


 100% agree.

 'bit' is a very small unsigned integer whose value is in the range 0
 (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number of
 bytes the the implementation uses.

 'bool' is NOT an integer. It can only have either of two values - TRUE or
 FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0
 for FALSE and 1 for TRUE.


 This is good. I vote for a bool type.


Good.

 Or at least an implicit cast
 from boolean expressions to bit.


Bad, IMO. May I ask what uses you see for implicit conversion, and/or your
objections to all such bool-integral conversions being explicit?

Cheers

Matthew

May 25 2004

"Bruno A. Costa" <bruno codata.com.br> writes:

Matthew wrote:

 
 "Bruno A. Costa" <bruno codata.com.br> wrote in message
 news:c8vc34$k50$1 digitaldaemon.com...
 Derek Parnell wrote:

 On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:

 [snip]

 Personally, I would favor two distinct types: bit and bool, with bit
 being considered an arithmetic type (like a one bit wide unsigned
 integer), and bool able only to take values true and false. In this
 scenario, bits could be auto-promoted to int or uint (since those
 would be widening conversions) but bool could not (because logical
 types should not auto-convert to arithmetic types).


 100% agree.

 'bit' is a very small unsigned integer whose value is in the range 0
 (zero) to 1 (one). And I presume 'sizeof(bit)' should return the number
 of bytes the the implementation uses.

 'bool' is NOT an integer. It can only have either of two values - TRUE
 or FALSE. But to make some people's lives a bit easier 'cast(bit)bool'
 ==> 0 for FALSE and 1 for TRUE.


 This is good. I vote for a bool type.


 Good.
 
 Or at least an implicit cast
 from boolean expressions to bit.


 Bad, IMO. May I ask what uses you see for implicit conversion, and/or your
 objections to all such bool-integral conversions being explicit?
 
 Cheers
 
 Matthew


Well, as I said, my vote is for a bool type. The second option (but
not the best option) is just to avoid casts like:

bit b;
b = cast(bit) (a==c);


So, I think we should stay witn the best.


Bruno.

May 25 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

Arcane Jill wrote:

Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false. 


functionality.  However I do think bit should work for all cases a bool 
would work.

-- 
-Anderson: http://badmama.com.au/~anderson/

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

 Arcane Jill wrote:

Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false.


 functionality.  However I do think bit should work for all cases a bool
 would work.



In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean
type is exactly that.

I see no more commonality between them as between a pointer and, on a 32-bit
architecture, int.

We very much need a boolean type, otherwise the (IMO) majority of us who
want/need one will provide our own (as I have in std.recls,
std.windows.registry,
etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is in.

May 25 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

Matthew wrote:

Arcane Jill wrote:

    

Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false.

      


functionality.  However I do think bit should work for all cases a bool
would work.
    



In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean
type is exactly that.
  



bool x;

if (x)
{

}

bit x;

if (x)
{

}

what's the difference between these functions?

bit x = true;

bool x = true;

What's the difference?

bit has more functionality but it still supports all the functionality 
of bool.

I see no more commonality between them as between a pointer and, on a 32-bit
architecture, int.

We very much need a boolean type, otherwise the (IMO) majority of us who
want/need one will provide our own (as I have in std.recls,
std.windows.registry,
etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is in.
  


bit doesn't loose all the functionality it has now I guess a bool type 
could be useful as sub-set of bit to prevent users from specifying 
numbers into functions.

-- 
-Anderson: http://badmama.com.au/~anderson/

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c8vbnc$jfd$1 digitaldaemon.com...
 Matthew wrote:

Arcane Jill wrote:



Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and








able only to take values true and false.


functionality.  However I do think bit should work for all cases a bool
would work.



In what ways do they overlap? bit is a 1-bit integer value, whereas a boolean
type is exactly that.



 bool x;

 if (x)
 {

 }

 bit x;

 if (x)
 {

 }

 what's the difference between these functions?

 bit x = true;

 bool x = true;

 What's the difference?


What's the difference between

bit x = true;

if(x){}

void *pv = cast(void*)(1);

if(pv){}

It's the same argument. Too logically unrelated types can be made to seem to
have
the same semantics in a limited set of circumstances. But this is a fool's
paradise - not saying you're a fool, of course; I'd be direct if I was saying
that ;) - since it is the ways in which the similarities fall down which catch
us
out. <self-promotion>I give a good long rant about this in Imperfect C++ - only
a
couple more months ...</self-promotion>

IMO, the "if(pv)" above should be illegal, and all conditional (sub-)expressions
must be explicitly boolean.

Thus

    int i;

    if(i) // error
    if(i != 0) // ok

    if(pv) // error
    if(null !== pv) // ok

This does not appeal to fans of terse code, but it does appeal to fans of
maintenance and unambiguity.

Flame away, sigh ...

 bit has more functionality but it still supports all the functionality
 of bool.

I see no more commonality between them as between a pointer and, on a 32-bit
architecture, int.

We very much need a boolean type, otherwise the (IMO) majority of us who
want/need one will provide our own (as I have in std.recls,




etc.) and we'll end up in exactly the same still-stinking mess that C/C++ is






 bit doesn't loose all the functionality it has now I guess a bool type
 could be useful as sub-set of bit to prevent users from specifying
 numbers into functions.


I don't propose any change in bit whatsoever, save that true and false may no
longer be implicitly used by it, or any other integral type. I want a boolean
type that is:

- not implicitly convertible to any other type
- is the type of all conditional expressions
- is of variable size, according to context. It would default to a (time)
efficiently representation as the same size as the architecture, e.g. 32-bits,
in
order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation. However,
it
could be align'd to any alignment, right down to 1-bit, according to the user's
decision. The compiler will handle all issues regarding accessing by pointer.
(The one issue here is that accessing a bit by pointer is tricky, but could be
achieve by having a boolean ptr as a two-value entity. Not sure about this one
as
yet, however ...)

These changes would make things ridiculously simple and umabiguous, without
causing any of the storage or performance or correctness problems encountered in
the boolean types of C/C++/Java.

May 25 2004

Hauke Duden <H.NS.Duden gmx.net> writes:

Matthew wrote:
 I don't propose any change in bit whatsoever, save that true and false may no
 longer be implicitly used by it, or any other integral type. I want a boolean
 type that is:
 
 - not implicitly convertible to any other type
 - is the type of all conditional expressions
 - is of variable size, according to context. It would default to a (time)
 efficiently representation as the same size as the architecture, e.g. 32-bits,
in
 order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation. However,
it
 could be align'd to any alignment, right down to 1-bit, according to the user's
 decision. The compiler will handle all issues regarding accessing by pointer.
 (The one issue here is that accessing a bit by pointer is tricky, but could be
 achieve by having a boolean ptr as a two-value entity. Not sure about this one
as
 yet, however ...)


For what it's worth, I completely agree with Matthew. At least with his 
first two points.

I'm not sure if the size saving argument of point 3 really justifies the 
complexity of having a type with a variable size, though. My gut tells 
me that this kind of thing can cause lots of headaches and bug 
opportunities, both for the compiler writer and for the programmer who 
uses it.

I'd be happy if bool would be implemented(!) as an int, where !=0 is the 
same as true and 0 is false. So it basically means that the compiler has 
to translate bool==true to bool!=0 instead of bool==1 and boolA==boolB 
to a suitable construct that ensures correctness. Otherwise it could 
internally be treated as a typedef'ed int without arithmetic operations. 
Even Walter could use such a bool type ;) (he currently uses int instead 
of bit because int is faster).

The need to conserve memory for bools is so rare that I think this would 
be sufficient and it has the added benefit of being dead simple. If size 
should really become an issue (for example with huge bool arrays) the 
programmer still has the option to use bit instead. He won't have the 
advantages of a real bool type then, but at least he will be aware of 
the issues (since he explicitly chose bit) and can deal with them properly.

Note that I'm only talking about the internal implementation here. Bool 
should still be a completely independent type, of course, with no 
implicit conversions.

Hauke



 
 These changes would make things ridiculously simple and umabiguous, without
 causing any of the storage or performance or correctness problems encountered
in
 the boolean types of C/C++/Java.

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c8vg4g$r6t$1 digitaldaemon.com...
 Matthew wrote:
 I don't propose any change in bit whatsoever, save that true and false may no
 longer be implicitly used by it, or any other integral type. I want a boolean
 type that is:

 - not implicitly convertible to any other type
 - is the type of all conditional expressions
 - is of variable size, according to context. It would default to a (time)
 efficiently representation as the same size as the architecture, e.g.




 order to avoid the costs in the implicit "b = !b ? 0 : 1" evaluation.




 could be align'd to any alignment, right down to 1-bit, according to the




 decision. The compiler will handle all issues regarding accessing by pointer.
 (The one issue here is that accessing a bit by pointer is tricky, but could




 achieve by having a boolean ptr as a two-value entity. Not sure about this




 yet, however ...)


 For what it's worth, I completely agree with Matthew. At least with his
 first two points.

 I'm not sure if the size saving argument of point 3 really justifies the
 complexity of having a type with a variable size, though. My gut tells
 me that this kind of thing can cause lots of headaches and bug
 opportunities, both for the compiler writer and for the programmer who
 uses it.

 I'd be happy if bool would be implemented(!) as an int, where !=0 is the
 same as true and 0 is false. So it basically means that the compiler has
 to translate bool==true to bool!=0 instead of bool==1 and boolA==boolB
 to a suitable construct that ensures correctness. Otherwise it could
 internally be treated as a typedef'ed int without arithmetic operations.
 Even Walter could use such a bool type ;) (he currently uses int instead
 of bit because int is faster).

 The need to conserve memory for bools is so rare that I think this would
 be sufficient and it has the added benefit of being dead simple. If size
 should really become an issue (for example with huge bool arrays) the
 programmer still has the option to use bit instead. He won't have the
 advantages of a real bool type then, but at least he will be aware of
 the issues (since he explicitly chose bit) and can deal with them properly.

 Note that I'm only talking about the internal implementation here. Bool
 should still be a completely independent type, of course, with no
 implicit conversions.


Actually, I completely agree with you. I was just pandering to the violent
objectors, if they're still involving themselves, that came out the last time I
asked for sizeof(boolean) to be sizeof(register), late last year.

May 25 2004

Juan C <Juan_member pathlink.com> writes:

- not implicitly convertible to any other type


Nor _from_ any type.

May 25 2004

Arcane Jill <Arcane_member pathlink.com> writes:

In article <c8vbnc$jfd$1 digitaldaemon.com>, J Anderson says...

bool x;

if (x)
{

}

bit x;

if (x)
{

}

what's the difference between these functions?


The first would be legitimate.
The second would be a syntax error. The compiler would require if (x==1).



bit x = true;

bool x = true;

What's the difference?


The first would be syntax error. The compiler would require bit x = 1;
The second would be legitimate.



Ok I've thought about it a bit more.  Your probably right, as long as 
bit doesn't loose all the functionality it has now I guess a bool type 
could be useful as sub-set of bit to prevent users from specifying 
numbers into functions.


Not a subset. In fact, not interchangable AT ALL without an explicit cast.

Arcane Jill

May 25 2004

James McComb <alan jamesmccomb.id.au> writes:

J Anderson wrote:

 I'm against having two types.  Bit and bool overlap on just about all 
 functionality.


I understand what you mean, but strictly speaking, if bit is arithmetic 
and bool is logical, they don't overlap at all.

Interface for bit: +, -, * , / etc.
Interface for bool: &&, || etc.

James McComb

May 25 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

James McComb wrote:

 J Anderson wrote:

 I'm against having two types.  Bit and bool overlap on just about all 
 functionality.



 I understand what you mean, but strictly speaking, if bit is 
 arithmetic and bool is logical, they don't overlap at all.

 Interface for bit: +, -, * , / etc.
 Interface for bool: &&, || etc.

 James McComb


So a bit isn't a integer like Matthew suggests then?

-- 
-Anderson: http://badmama.com.au/~anderson/

May 25 2004

James McComb <alan jamesmccomb.id.au> writes:

J Anderson wrote:

 Interface for bit: +, -, * , / etc.
 Interface for bool: &&, || etc.


 So a bit isn't a integer like Matthew suggests then?


Yes, I think that bit should be a type of integer.

A bit should be an integer with a value ranging from 0 to 1 inclusive.
It could be safely promoted to larger integer types.

A bool should be a type with the non-numeric values true and false.
An explicit cast would be required to convert to and from bool.

I believe Arcane Jill is advocating the same thing.

James McComb

May 25 2004

James McComb <alan jamesmccomb.id.au> writes:

James McComb wrote:

 A bit should be an integer with a value ranging from 0 to 1 inclusive.
 It could be safely promoted to larger integer types.
 
 A bool should be a type with the non-numeric values true and false.
 An explicit cast would be required to convert to and from bool.


In addition, I'm also happy with the idea of bool being implemented 
internally as an int.

James McComb

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"James McComb" <alan jamesmccomb.id.au> wrote in message
news:c913e1$8ho$1 digitaldaemon.com...
 James McComb wrote:

 A bit should be an integer with a value ranging from 0 to 1 inclusive.
 It could be safely promoted to larger integer types.

 A bool should be a type with the non-numeric values true and false.
 An explicit cast would be required to convert to and from bool.


 In addition, I'm also happy with the idea of bool being implemented
 internally as an int.



It's inefficient. Consider the following boolean sub-expression:

    void *pv = ...

    if(null !== pv)
    {}

That's all ok, and perfectly efficient. The compiler simply tests pv against 0.
However, what if we want to remember the expr, as in

    bool b = (null !== pv);

The compiler then has to do the following (assuming 32-bit arch):

    b = (0 != (cast(uint)(pv) & 0xffffffff) ? 1 : 0

This is what happens in C++ with a vast majority of current C++ compilers not
warning you about the performance hit. (See "Imperfect C++", in Sept, for the
full details for this and other boolean blunders.)

Thus, a boolean type must be the size of the natural int size of the
architecture. The only question remains whether we have something special going
on for boolean arrays or not. If we do, and if an element in the boolean array
is
< 1-byte, then there are the addressing problems.

Unless I've seriously missed something in my deliberations on this subject over
several years, along with all the people who've opined on this issue on this NG
for the last couple of years, there is *no way* to satisfy all the requirements
of space efficiency, time efficiency and addressability of a boolean type.

That being the case, maybe the way forward is to have the boolean type the size
of the natural int size of the architecture, and have standard library bit
container(s)?

Thoughts, everyone?

May 25 2004

Andy Friesen <andy ikagames.com> writes:

Matthew wrote:

 Unless I've seriously missed something in my deliberations on this subject over
 several years, along with all the people who've opined on this issue on this NG
 for the last couple of years, there is *no way* to satisfy all the requirements
 of space efficiency, time efficiency and addressability of a boolean type.
 
 That being the case, maybe the way forward is to have the boolean type the size
 of the natural int size of the architecture, and have standard library bit
 container(s)?
 
 Thoughts, everyone?


This sounds fine to me.  It's consistent, easy to explain (and thus 
understand), and convenient for the hardware.

One thing that kind of bugs me, though, is what all those other bits 
mean.  In a "nice" D application, they would always be unset, but D code 
doesn't have to be nice. (pointer coersion and so forth) So is the truth 
value of a bool based on its zero-ness, purely on the lowest bit, or 
what? (does it even matter?)

  -- andy

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Andy Friesen" <andy ikagames.com> wrote in message
news:c915cr$bv0$1 digitaldaemon.com...
 Matthew wrote:

 Unless I've seriously missed something in my deliberations on this subject




 several years, along with all the people who've opined on this issue on this




 for the last couple of years, there is *no way* to satisfy all the




 of space efficiency, time efficiency and addressability of a boolean type.

 That being the case, maybe the way forward is to have the boolean type the




 of the natural int size of the architecture, and have standard library bit
 container(s)?

 Thoughts, everyone?


 This sounds fine to me.  It's consistent, easy to explain (and thus
 understand), and convenient for the hardware.

 One thing that kind of bugs me, though, is what all those other bits
 mean.  In a "nice" D application, they would always be unset, but D code
 doesn't have to be nice. (pointer coersion and so forth) So is the truth
 value of a bool based on its zero-ness, purely on the lowest bit, or
 what? (does it even matter?)


It would depend on the context.

For boolean sub-expression testing we can use the architecture-width
optimistically efficient "if" or "if not". Hence, the following code

    void    *pv =
    int        i    =
    short    s    =

    if(    null === pv &&
           0 == i &&
           0 != s)

would be translatable to (machine speak)

    if(    0 == pv &&     /* This is a 32-bit test, e.g. cmp eax, 0. (Remember,
pv is an int, to the processer) */
           0 == i &&        /* So is this. */
           0 != s)              /* This is a 16-bit test, e.g. cmp ax, 0 */

However, for conversions, which would be explicit, the compiler would have to
step in. Consider

    void    *pv = cast(void*)(0xffff0000);
    bit       t     =    cast(boolean)(pv !== null);

If the (second) cast only passed the bit pattern, the truncation error would
yield b = 0. Not what we wanted, since the integral value of the boolean
sub-expression "pv !== null" is true, which must convert to 1, not 0, in
integral
form.

This means that the compiler must do the inefficient comparison and value
selection mentioned in a previous post, as in

    void    *pv = cast(void*)(0xffff0000);
    bit       t     =    (pv !== null) ? 1 : 0;

This is one more reason, along with logic, and avoidance of errors, why
conversions to and from boolean types (and sub-expressions) must be only
available with a cast, since they are inefficient.

Walter, you convinced yet?

May 25 2004

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <c9179j$fag$1 digitaldaemon.com>, Matthew says...


This is one more reason, along with logic, and avoidance of errors, why
conversions to and from boolean types (and sub-expressions) must be only
available with a cast, since they are inefficient.

Walter, you convinced yet?


He, he, I think it's just impossible to convince Walter about this.
We'll add the boolean type in the first ISO standard draft ;-)

BTW, would you like to add your good argumentation on the wiky page at
http://www.wikiservice.at/wiki4d/wiki.cgi?BooleanNotEquBit

Ciao

May 26 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Roberto Mariottini" <Roberto_member pathlink.com> wrote in message
news:c91il7$10h8$1 digitaldaemon.com...
 In article <c9179j$fag$1 digitaldaemon.com>, Matthew says...


This is one more reason, along with logic, and avoidance of errors, why
conversions to and from boolean types (and sub-expressions) must be only
available with a cast, since they are inefficient.

Walter, you convinced yet?


 He, he, I think it's just impossible to convince Walter about this.
 We'll add the boolean type in the first ISO standard draft ;-)


Well, if he wants me to write a book about D, I'm going to be giving my true and
honest opinions. ;)

 BTW, would you like to add your good argumentation on the wiky page at
 http://www.wikiservice.at/wiki4d/wiki.cgi?BooleanNotEquBit


No, but I'm happy for you to quote me, if you have the time.

May 26 2004

Arcane Jill <Arcane_member pathlink.com> writes:

Walter, you convinced yet?


 He, he, I think it's just impossible to convince Walter about this.
 We'll add the boolean type in the first ISO standard draft ;-)




There is another, as yet unmentioned reason, why the type bool should exist, and
should NOT be considered arithmetic. How many times have you guys written the
following bug into your code? :

       if (a = b)


instead of:

       if (a == b)


Show me someone who answers "never", and I'll show you someone who doesn't write
software. With a bool type, that bug would be a compile-time error, requiring
you to change it to one of:

       if (a == b)         // if it was a bug, or
       if ((a = b) != 0)   // if it was deliberate


Convinced yet? There's almost unanimous support for a non-arithmetic bool...
Arcane Jill

May 27 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c943n8$1mdk$1 digitaldaemon.com...
Walter, you convinced yet?


 He, he, I think it's just impossible to convince Walter about this.
 We'll add the boolean type in the first ISO standard draft ;-)




 There is another, as yet unmentioned reason, why the type bool should


 should NOT be considered arithmetic. How many times have you guys written


 following bug into your code? :

       if (a = b)


 instead of:

       if (a == b)


 Show me someone who answers "never", and I'll show you someone who doesn't


 software. With a bool type, that bug would be a compile-time error,


 you to change it to one of:


I agree that we need a real bool type, but have you tried that? It doesn't
work
i get the error message:
E:\Developement\D\Projects\factoriel\factoriel.d(20): '=' does not give a
boolean result
when i try if(a=b)

       if (a == b)         // if it was a bug, or
       if ((a = b) != 0)   // if it was deliberate


 Convinced yet? There's almost unanimous support for a non-arithmetic


 Arcane Jill


I was allready convinced :)

May 27 2004

Arcane Jill <Arcane_member pathlink.com> writes:

Incidently (and again, this is only a semi-serious suggestion, and I don't care
if anyone floors this with a rational argument), is there any reason why the
type of the sizeof property has to be int for every type?

I mean, bit.sizeof were to return a float instead of an int, then it could
return its conceptual size of 0.125 bytes.

(Of course, malloc(float) and similar would then have to be defined to round up,
not down!)

Jill

May 27 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

I certainly hope the type is not int _now_! It should be uint, and there's an
argument for it being ulong, although that's perhaps only in D-64.

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c96nrd$anp$1 digitaldaemon.com...
 Incidently (and again, this is only a semi-serious suggestion, and I don't care
 if anyone floors this with a rational argument), is there any reason why the
 type of the sizeof property has to be int for every type?

 I mean, bit.sizeof were to return a float instead of an int, then it could
 return its conceptual size of 0.125 bytes.

 (Of course, malloc(float) and similar would then have to be defined to round


 not down!)

 Jill

May 28 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

Arcane Jill wrote:

Incidently (and again, this is only a semi-serious suggestion, and I don't care
if anyone floors this with a rational argument), is there any reason why the
type of the sizeof property has to be int for every type?

I mean, bit.sizeof were to return a float instead of an int, then it could
return its conceptual size of 0.125 bytes.

(Of course, malloc(float) and similar would then have to be defined to round up,
not down!)

Jill
  




-- 
-Anderson: http://badmama.com.au/~anderson/

May 28 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c943n8$1mdk$1 digitaldaemon.com...
Walter, you convinced yet?


 He, he, I think it's just impossible to convince Walter about this.
 We'll add the boolean type in the first ISO standard draft ;-)




 There is another, as yet unmentioned reason, why the type bool should exist,


 should NOT be considered arithmetic. How many times have you guys written the
 following bug into your code? :

       if (a = b)


 instead of:

       if (a == b)


 Show me someone who answers "never", and I'll show you someone who doesn't


 software. With a bool type, that bug would be a compile-time error, requiring
 you to change it to one of:

       if (a == b)         // if it was a bug, or
       if ((a = b) != 0)   // if it was deliberate


 Convinced yet? There's almost unanimous support for a non-arithmetic bool...
 Arcane Jill


I can't say "never", but I can say "not once in the last three years".

See "Imperfect C++" (if you can wait for September 9th;
http://www.awprofessional.com/titles/0321228774/) for several different
pejorative rants on this topic. ;)

May 27 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

Sounds like we're all just about on the same page.

Walter?

"James McComb" <alan jamesmccomb.id.au> wrote in message
news:c912or$7mt$1 digitaldaemon.com...
 J Anderson wrote:

 Interface for bit: +, -, * , / etc.
 Interface for bool: &&, || etc.


 So a bit isn't a integer like Matthew suggests then?


 Yes, I think that bit should be a type of integer.

 A bit should be an integer with a value ranging from 0 to 1 inclusive.
 It could be safely promoted to larger integer types.

 A bool should be a type with the non-numeric values true and false.
 An explicit cast would be required to convert to and from bool.

 I believe Arcane Jill is advocating the same thing.

 James McComb

May 25 2004

Derek Parnell <derek psych.ward> writes:

On Tue, 25 May 2004 19:22:30 +0800, J Anderson wrote:

 Arcane Jill wrote:
 
Personally, I would favor two distinct types: bit and bool, with bit being
considered an arithmetic type (like a one bit wide unsigned integer), and bool
able only to take values true and false. 


 functionality.  However I do think bit should work for all cases a bool 
 would work.


Well actually that turns out not to be the case.

 int a;
 bit b;
 bool c;
 int d;


 a = 5;
 b = 1;
 c = true;

 d = a + b; // Ok, makes sense.
 d = a + c; // Not ok. Does not make sense.

 d = a + cast(bit)c; // Well if you real have to...

that last line is really another way of saying ...

 d = a + (c ? 1 : 0);

  
-- 
Derek
26/May/04 9:30:45 AM

May 25 2004

Juan C <Juan_member pathlink.com> writes:

 d = a + cast(bit)c; // Well if you real have to...

that last line is really another way of saying ...

 d = a + (c ? 1 : 0);


No, the former line is evil, and the latter is preferred.

The former would be kinda like trying to do
int x = cast(int) "123" ;
what are you going to get? Certainly not the integer value 123 which appears to
be the goal. (Granted you may want to do this some time for some reason, I
have.)

<soapbox>
Although I'm sure that if boolean is changed in the language as proposed it will
be implemented in such a way that the former will work, but it's best not to
expect it to. Why demand that boolean be a true (whoops) boolean and then allow
non-boolean access thereto? There should be no meaningful way to cast to or from
boolean, only a test should work. Think of the equality, relational, and trinary
operators as "casts" for boolean.

Part of the goal (in my mind anyway) is to retrain C programmers from thinking
of booleans as integers. Booleans are _not_ numeric values!
</soapbox>

May 25 2004

Derek Parnell <derek psych.ward> writes:

On Wed, 26 May 2004 00:37:38 +0000 (UTC), Juan C wrote:

 d = a + cast(bit)c; // Well if you real have to...

that last line is really another way of saying ...

 d = a + (c ? 1 : 0);


 No, the former line is evil, and the latter is preferred.


I agree. I was just trying to suggest a compromise, or concession, to help
get the bool/bit/int differentiation across the line. ;-)

 
 The former would be kinda like trying to do
 int x = cast(int) "123" ;
 what are you going to get? Certainly not the integer value 123 which appears to
 be the goal. (Granted you may want to do this some time for some reason, I
 have.)


Yeah, we all know what you intend here, so maybe this is not such an 'evil'
example. The 'cast' is explicitly saying "please convert the subject into
the format that I'm specifying". In your example, convert "123" into an
integer. 

 <soapbox>
 Although I'm sure that if boolean is changed in the language as proposed it
will
 be implemented in such a way that the former will work, but it's best not to
 expect it to. Why demand that boolean be a true (whoops) boolean and then allow
 non-boolean access thereto? There should be no meaningful way to cast to or
from
 boolean, only a test should work. Think of the equality, relational, and
trinary
 operators as "casts" for boolean.
 
 Part of the goal (in my mind anyway) is to retrain C programmers from thinking
 of booleans as integers. Booleans are _not_ numeric values!
 </soapbox>


Not a bad goal at all; sign me up for the Cause.
-- 
Derek
26/May/04 10:44:50 AM

May 25 2004

Regan Heath <regan netwin.co.nz> writes:

On Wed, 26 May 2004 10:49:45 +1000, Derek Parnell <derek psych.ward> wrote:
 The former would be kinda like trying to do
 int x = cast(int) "123" ;
 what are you going to get? Certainly not the integer value 123 which 
 appears to
 be the goal. (Granted you may want to do this some time for some 
 reason, I
 have.)


 Yeah, we all know what you intend here, so maybe this is not such an 
 'evil'
 example. The 'cast' is explicitly saying "please convert the subject into
 the format that I'm specifying". In your example, convert "123" into an
 integer.


OR.. is x supposed to be set to the bits involved in the ascii characters 
"123" in that order?

This is not such a silly suggestion if you're writing a text encryption 
routine that swaps bits on 32 bit boundaries.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

May 25 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"Juan C" <Juan_member pathlink.com> wrote in message
news:c90osi$2rmp$1 digitaldaemon.com...
 d = a + cast(bit)c; // Well if you real have to...

that last line is really another way of saying ...

 d = a + (c ? 1 : 0);


 No, the former line is evil, and the latter is preferred.

 The former would be kinda like trying to do
 int x = cast(int) "123" ;
 what are you going to get? Certainly not the integer value 123 which appears to
 be the goal. (Granted you may want to do this some time for some reason, I
 have.)

 <soapbox>
 Although I'm sure that if boolean is changed in the language as proposed it


 be implemented in such a way that the former will work, but it's best not to
 expect it to. Why demand that boolean be a true (whoops) boolean and then allow
 non-boolean access thereto? There should be no meaningful way to cast to or


 boolean, only a test should work. Think of the equality, relational, and


 operators as "casts" for boolean.

 Part of the goal (in my mind anyway) is to retrain C programmers from thinking
 of booleans as integers. Booleans are _not_ numeric values!
 </soapbox>


Hear, hear!

May 25 2004

James McComb <alan jamesmccomb.id.au> writes:

Arcane Jill wrote:

 Personally, I would favor two distinct types: bit and bool, with bit being
 considered an arithmetic type (like a one bit wide unsigned integer), and bool
 able only to take values true and false. In this scenario, bits could be
 auto-promoted to int or uint (since those would be widening conversions) but
 bool could not (because logical types should not auto-convert to arithmetic
 types).


+1. And expressions like (a == b) should return bool.

James McComb

May 25 2004

Roel Mathys <roel.mathys yucom.be> writes:

Arcane Jill wrote:
 Some problems and inconsistencies with bits.
 
 (1). The expression:
 
 
      (a == b)


 
 yields type int, not type bit. Indeed, the statement:
 
 
      bit b = (a == b);


 
 is rejected by the compiler, and must be transofmed into:
 
 
      bit b = cast(bit)(a==b);


 
 in order to compile.
 
 (2) (BUG). The statements:
 
 
      bit b = true;
      uint i = -b;


 
 leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.
 
 (3) The declaration:
 
 
      bit[256] b;


 
 creates an array of 256 bytes, not 32 bytes (which would be 256 bits in
total). 
 
 Arcane Jill
 
 


template F(bit value:true)
{
     void f() {printf("true\n");}
}

template F(bit value:false)
{
     void f() {printf("false\n");}
}



void main()
{
     F!(cast(bit)(1==1)).f();
     // F!(1==1).f(); // does crash the compiler
}



bye
roel

May 24 2004

Jesus <Jesus_member pathlink.com> writes:

(2) (BUG). The statements:

       bit b = true;
       uint i = -b;


leave i containing the value 0x000000FF. I would have expected 



This is because bit is implemented as a byte.

b = 0x01
-b = 0xFF = 255

cast(uint)(-b) = 0x000000FF = 255

The problem is you're using 2's complement arithmetic on unsigned 
types which doesn't semantically make sense, unless you're intending to 
use modular arithmetic.

If there were such a thing as a signed byte (there might be for all I know) 
and you converted it to a signed int with those statements then you would 
expect to get 0xFFFFFFFF = -1

Jun 30 2004

D Programming

C/C++ Programming

Other

digitalmars.D - Bits