www.digitalmars.com         C & C++   DMDScript  

D - bool == bit?

reply w <w_member pathlink.com> writes:
I don't know if this has been discussed before, and I couldn't find a "search"
in this forum, so...

Is "bit" D's boolean type? If it is, OK. But, if some people use bit, others use
int and others define a custom type, i'm afraid D will follow C's path (Let the
developer choose its boolean type. Then every library has a typedef for bool or
BOOL. After the mess, define a type with a strange name like _Bool...)
Sep 07 2003
next sibling parent "Vathix" <vathix dprogramming.com> writes:
It was origionally bit, but bool was recently added as an alias to bit.

"w" <w_member pathlink.com> wrote in message
news:bjg0d7$nke$1 digitaldaemon.com...

 I don't know if this has been discussed before, and I couldn't find a


"search"

 in this forum, so...

 Is "bit" D's boolean type? If it is, OK. But, if some people use bit,


others use

 int and others define a custom type, i'm afraid D will follow C's path


(Let the

 developer choose its boolean type. Then every library has a typedef for


bool or

 BOOL. After the mess, define a type with a strange name like _Bool...)
Sep 07 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
bit was originally to be used. bool is now an alias for bit.

There are *several* people who do not like this, but sadly Walter's not one
of them. Not that we don't keep trying to convince him every now and than.

I personally think that bool should be a distinct type, of the size of int,
and which cannot engage in implicit conversions to and from integer types.
Sadly, my sway is marginal, at best. :(

"w" <w_member pathlink.com> wrote in message
news:bjg0d7$nke$1 digitaldaemon.com...

 I don't know if this has been discussed before, and I couldn't find a


"search"

 in this forum, so...

 Is "bit" D's boolean type? If it is, OK. But, if some people use bit,


others use

 int and others define a custom type, i'm afraid D will follow C's path


(Let the

 developer choose its boolean type. Then every library has a typedef for


bool or

 BOOL. After the mess, define a type with a strange name like _Bool...)
Sep 07 2003
next sibling parent reply John Boucher <John_member pathlink.com> writes:
I like bool as a bit rather than as an int because by definition a bool is
limited to a set of two values, but an int can hold oh so many more.

My opinion is that with a bool the two operations not (!) and complement (~)
should return the same value, which is not always true with ints. Of course
maybe it doesn't make sense to perform complement on bools anyway, but I see no
reason not to allow it.

John Boucher
The King had Humpty pushed.
Sep 07 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
[Apologies up-front for the shameless egotism in trying out my new
signature. Sorry chaps.]

The argument against bool as a bit is that a bit cannot have its address
taken. That's an acceptable limitation, since everyone understands bits are
a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's not
in the least bit reasonable for a bool, and will lead to a profusion of
Bool, boolean, Boolean, _Bool types.

The argument against bool as a small type (i.e. 8 or 16-bits) is that there
are unavoidable inefficiencies in the following

 int i = . . .;
 bool b = i; // The compiler must replace this with bool b = i != 0;

I grant you this is less compelling, but this is a serious (from efficiency)
flaw of C++, and D is supposed to be answering the flaws in C++ - especially
the easy ones - so I just don't think doing the same thing is acceptable.

Naturally if implicit conversions to and from integers are disallowed this
kind of thing goes away. If people want implicit conversions, then
sizeof(bool) is an important matter.

Either way, it's about time we heard from the big guy on this. Walter?

Oh, as for ~ I think it's entirely inappropriate to have a bit-wise operator
on a type whose *entire* reason for being is to represent logical notions.
No ~ for bool for me please. (Another reason to move away from it being an
alias for bit.) The reason to disallow it is simple, it is not appropriate.
Languages are not suffering from a lack of malapplicable operators. Quite
the reverse. And I say this as one who has formerly committed all kinds of
transgressions in C++ over the years. I once implemented the ++ operator for
a string class!

-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs

----------------------------------------------------------------------------
---



"John Boucher" <John_member pathlink.com> wrote in message
news:bjgsj3$1vdf$1 digitaldaemon.com...

 I like bool as a bit rather than as an int because by definition a bool is
 limited to a set of two values, but an int can hold oh so many more.

 My opinion is that with a bool the two operations not (!) and complement


(~)

 should return the same value, which is not always true with ints. Of


course

 maybe it doesn't make sense to perform complement on bools anyway, but I


see no

 reason not to allow it.

 John Boucher
 The King had Humpty pushed.
Sep 07 2003
next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjgv8a$23cu$1 digitaldaemon.com...

 Languages are not suffering from a lack of malapplicable operators. Quite
 the reverse. And I say this as one who has formerly committed all kinds of
 transgressions in C++ over the years. I once implemented the ++ operator


for

 a string class!


In case you thought you were in for some prize, I've heard that someone was
as crazy as to implement bitshift operators on I/O streams!! :)

BTW, what in the world did that ++ do when applied to a string? Just
curious...

Ric
Sep 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bjhcei$2nku$2 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjgv8a$23cu$1 digitaldaemon.com...

 Languages are not suffering from a lack of malapplicable operators.




Quite

 the reverse. And I say this as one who has formerly committed all kinds




of

 transgressions in C++ over the years. I once implemented the ++ operator


 for

 a string class!


 In case you thought you were in for some prize, I've heard that someone


was

 as crazy as to implement bitshift operators on I/O streams!! :)

 BTW, what in the world did that ++ do when applied to a string? Just
 curious...


This is one of several of my former C++ criminality that're going into
Appendix B of my book. You'll have to buy it! ;)
Sep 08 2003
prev sibling next sibling parent reply "J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:
The last time this came up, I posted some comments about a line of thinking
that says bool arguments are overused.  If you buy into that argument (and
it does have some merit), then not being able to take the address of bool
isn't so bad.

   Dan

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjgv8a$23cu$1 digitaldaemon.com...

 [Apologies up-front for the shameless egotism in trying out my new
 signature. Sorry chaps.]

 The argument against bool as a bit is that a bit cannot have its address
 taken. That's an acceptable limitation, since everyone understands bits


are

 a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's


not

 in the least bit reasonable for a bool, and will lead to a profusion of
 Bool, boolean, Boolean, _Bool types.

 The argument against bool as a small type (i.e. 8 or 16-bits) is that


there

 are unavoidable inefficiencies in the following

  int i = . . .;
  bool b = i; // The compiler must replace this with bool b = i != 0;

 I grant you this is less compelling, but this is a serious (from


efficiency)

 flaw of C++, and D is supposed to be answering the flaws in C++ -


especially

 the easy ones - so I just don't think doing the same thing is acceptable.

 Naturally if implicit conversions to and from integers are disallowed this
 kind of thing goes away. If people want implicit conversions, then
 sizeof(bool) is an important matter.

 Either way, it's about time we heard from the big guy on this. Walter?

 Oh, as for ~ I think it's entirely inappropriate to have a bit-wise


operator

 on a type whose *entire* reason for being is to represent logical notions.
 No ~ for bool for me please. (Another reason to move away from it being an
 alias for bit.) The reason to disallow it is simple, it is not


appropriate.

 Languages are not suffering from a lack of malapplicable operators. Quite
 the reverse. And I say this as one who has formerly committed all kinds of
 transgressions in C++ over the years. I once implemented the ++ operator


for

 a string class!

 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
 Gibbs

 --------------------------------------------------------------------------


--

 ---



 "John Boucher" <John_member pathlink.com> wrote in message
 news:bjgsj3$1vdf$1 digitaldaemon.com...

 I like bool as a bit rather than as an int because by definition a bool




is

 limited to a set of two values, but an int can hold oh so many more.

 My opinion is that with a bool the two operations not (!) and complement


 (~)

 should return the same value, which is not always true with ints. Of


 course

 maybe it doesn't make sense to perform complement on bools anyway, but I


 see no

 reason not to allow it.

 John Boucher
 The King had Humpty pushed.
Sep 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
Sorry, I don't. :(

"J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> wrote in message
news:bji345$muf$1 digitaldaemon.com...

 The last time this came up, I posted some comments about a line of


thinking

 that says bool arguments are overused.  If you buy into that argument (and
 it does have some merit), then not being able to take the address of bool
 isn't so bad.

    Dan

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjgv8a$23cu$1 digitaldaemon.com...

 [Apologies up-front for the shameless egotism in trying out my new
 signature. Sorry chaps.]

 The argument against bool as a bit is that a bit cannot have its address
 taken. That's an acceptable limitation, since everyone understands bits


 are

 a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's


 not

 in the least bit reasonable for a bool, and will lead to a profusion of
 Bool, boolean, Boolean, _Bool types.

 The argument against bool as a small type (i.e. 8 or 16-bits) is that


 there

 are unavoidable inefficiencies in the following

  int i = . . .;
  bool b = i; // The compiler must replace this with bool b = i != 0;

 I grant you this is less compelling, but this is a serious (from


 efficiency)

 flaw of C++, and D is supposed to be answering the flaws in C++ -


 especially

 the easy ones - so I just don't think doing the same thing is




acceptable.

 Naturally if implicit conversions to and from integers are disallowed




this

 kind of thing goes away. If people want implicit conversions, then
 sizeof(bool) is an important matter.

 Either way, it's about time we heard from the big guy on this. Walter?

 Oh, as for ~ I think it's entirely inappropriate to have a bit-wise


 operator

 on a type whose *entire* reason for being is to represent logical




notions.

 No ~ for bool for me please. (Another reason to move away from it being




an

 alias for bit.) The reason to disallow it is simple, it is not


 appropriate.

 Languages are not suffering from a lack of malapplicable operators.




Quite

 the reverse. And I say this as one who has formerly committed all kinds




of

 transgressions in C++ over the years. I once implemented the ++ operator


 for

 a string class!

 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
 (www.synesis.com.au/articles.html#columns)

 "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
 Gibbs


 --------------------------------------------------------------------------
 --

 ---



 "John Boucher" <John_member pathlink.com> wrote in message
 news:bjgsj3$1vdf$1 digitaldaemon.com...

 I like bool as a bit rather than as an int because by definition a






bool

 is

 limited to a set of two values, but an int can hold oh so many more.

 My opinion is that with a bool the two operations not (!) and






complement

 (~)

 should return the same value, which is not always true with ints. Of


 course

 maybe it doesn't make sense to perform complement on bools anyway, but






I

 see no

 reason not to allow it.

 John Boucher
 The King had Humpty pushed.
Sep 08 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I thought Walter made it so that you can take the address of a bit and pass
it by reference?

Bool should be a 1-bit type that the compiler can store in a byte or int if
it wants.  You should not have any guarantee in the language regarding the
size of bool.  If you, the programmer, need to know, use the .size property.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjgv8a$23cu$1 digitaldaemon.com...

 The argument against bool as a bit is that a bit cannot have its address
 taken. That's an acceptable limitation, since everyone understands bits


are

 a sub-unit of the "lowest addressable unit", i.e. a byte. However, it's


not

 in the least bit reasonable for a bool, and will lead to a profusion of
 Bool, boolean, Boolean, _Bool types.

 The argument against bool as a small type (i.e. 8 or 16-bits) is that


there

 are unavoidable inefficiencies in the following

  int i = . . .;
  bool b = i; // The compiler must replace this with bool b = i != 0;

 I grant you this is less compelling, but this is a serious (from


efficiency)

 flaw of C++, and D is supposed to be answering the flaws in C++ -


especially

 the easy ones - so I just don't think doing the same thing is acceptable.

 Naturally if implicit conversions to and from integers are disallowed this
 kind of thing goes away. If people want implicit conversions, then
 sizeof(bool) is an important matter.
Sep 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 I thought Walter made it so that you can take the address of a bit and


pass

 it by reference?


I'd forgotten that discussion.


 Bool should be a 1-bit type that the compiler can store in a byte or int


if

 it wants.  You should not have any guarantee in the language regarding the
 size of bool.  If you, the programmer, need to know, use the .size


property.

I'm 100% with you there, apart from the .size thing. I'm not sure one would
even want to take the size of a bool. (Of course, when writing serialsiation
code it might be necessary. Hmm. Thinking)
Sep 08 2003
prev sibling next sibling parent reply John Boucher <John_member pathlink.com> writes:
If the language is strongly typed, shouldn't this produce a compile-time error?
I hope it would. Why add a bool type except to type it strongly?


 int i = . . .;
 bool b = i; // The compiler must replace this with bool b = i != 0;


John Boucher
The King had Humpty pushed.
Sep 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
That would be nice. I was just talking about the (likely) case where
implicit int<=>bool conversions are allowed (sigh).

"John Boucher" <John_member pathlink.com> wrote in message
news:bjic5b$14j7$1 digitaldaemon.com...

 If the language is strongly typed, shouldn't this produce a compile-time


error?

 I hope it would. Why add a bool type except to type it strongly?


 int i = . . .;
 bool b = i; // The compiler must replace this with bool b = i != 0;
Sep 08 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjgv8a$23cu$1 digitaldaemon.com...

 The argument against bool as a bit is that a bit cannot have its address
 taken.


Except that now you can!
Oct 31 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Can a bit be involved in implicit integral promotions?

If so, give me a strong bool type!

"Walter" <walter digitalmars.com> wrote in message
news:bnupbd$gi8$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjgv8a$23cu$1 digitaldaemon.com...

 The argument against bool as a bit is that a bit cannot have its address
 taken.


 Except that now you can!
Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnupsk$he1$1 digitaldaemon.com...

 Can a bit be involved in implicit integral promotions?


Yes, it can be promoted, but not demoted.


 If so, give me a strong bool type!

 "Walter" <walter digitalmars.com> wrote in message
 news:bnupbd$gi8$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjgv8a$23cu$1 digitaldaemon.com...

 The argument against bool as a bit is that a bit cannot have its






address

 taken.


 Except that now you can!
Oct 31 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bnv1n0$s56$1 digitaldaemon.com...

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnupsk$he1$1 digitaldaemon.com...

 Can a bit be involved in implicit integral promotions?


 Yes, it can be promoted, but not demoted.


I suspected as much. :(


 If so, give me a strong bool type!




I refer the honourable gentleman to the presumptuous directive I gave some
moments ago
Oct 31 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bnv224$siq$1 digitaldaemon.com...

 If so, give me a strong bool type!




 I refer the honourable gentleman to the presumptuous directive I gave some
 moments ago


I understand how you feel about it, but I think we'll just have to agree to
disagree!
Oct 31 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnv224$siq$1 digitaldaemon.com...

 If so, give me a strong bool type!




 I refer the honourable gentleman to the presumptuous directive I gave




some

 moments ago


 I understand how you feel about it, but I think we'll just have to agree


to

 disagree!


Bad Walter! No dessert for you
Oct 31 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Boolean algebra is a distinct and separate algebra from real or integer
algebras.  It supports a much smaller set of operations and possible values.
I guess the closest numeric representation would be a modulo-2 integer
arithmetic.  And while I would ordinarily want D to as much as possible
allow us as users to create such low-level types ourselves, this still falls
into the category of "everyone will want it", and it's a good idea to
standardize such a thing before too many incompatible implementations are
created.

Boolean            Numeric Equivalent
===================
and                 * or min
or                      max or saturating +
xor                  modular +

But not many of the other operations (division, etc) make sense in a boolean
context.  For instance, what boolean value would you use to represent the
result of true divided by false?  ;)  Implicit conversions, while handy, can
also lead to hard-to-find logical errors that the compiler won't warn you
about.  After having worked with very low level assembly, I find it annoying
that C/C++ always promote the result of any sized integer operation to int
or long... that means the semantics of certain operations cannot be
supported by hardware byte registers;  it's constantly promoting the bytes
up to int behind your back.  That kind of thing can sure impact the
performance of a tight inner loop.

Bit, as a concept, is also a quite valuable tool, having many potential uses
above and beyond what D currently supports.  I believe I rambled on about
such a while back.  For instance, named slices of a bit array could be used
as bitfields, if conversion between bit array slice and integral types were
allowed.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bnvk4b$1l5k$1 digitaldaemon.com...

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bnv224$siq$1 digitaldaemon.com...

 If so, give me a strong bool type!




 I refer the honourable gentleman to the presumptuous directive I gave so




me

 moments ago


 I understand how you feel about it, but I think we'll just have to agree


to

 disagree!
Nov 01 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
"Sean L. Palmer" wrote:

 
 Boolean algebra is a distinct and separate algebra from real or integer
 algebras.  It supports a much smaller set of operations and possible values.
 I guess the closest numeric representation would be a modulo-2 integer
 arithmetic.  And while I would ordinarily want D to as much as possible
 allow us as users to create such low-level types ourselves, this still falls
 into the category of "everyone will want it", and it's a good idea to
 standardize such a thing before too many incompatible implementations are
 created.
 
 Boolean            Numeric Equivalent
 ===================
 and                 * or min
 or                      max or saturating +
 xor                  modular +


wouldn't it be nice to include such things as

  nand
  nor

given their real world importance?

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Nov 01 2003
next sibling parent reply Juan C <Juan_member pathlink.com> writes:
Indeed, booleans are _not_ numbers, they're _booleans_ there should be no
implicit conversions in either direction. The common use of the symbols "0" and
"1" to indicate the boolean values is not to be taken as anything but a
convenience, which is why we as nerds usually use "false" and "true". 

Boolean should be strongly typed and I don't care about how it is represented
behind the scenes. If you also want a one-bit number (whatever that's worth)
then you have the bit. But a bit is _not_ a boolean!

In article <3FA3964B.1881EEC7 chello.at>, Helmut Leitner says...

"Sean L. Palmer" wrote:

 
 Boolean algebra is a distinct and separate algebra from real or integer
 algebras.  It supports a much smaller set of operations and possible values.
 I guess the closest numeric representation would be a modulo-2 integer
 arithmetic.  And while I would ordinarily want D to as much as possible
 allow us as users to create such low-level types ourselves, this still falls
 into the category of "everyone will want it", and it's a good idea to
 standardize such a thing before too many incompatible implementations are
 created.
 
 Boolean            Numeric Equivalent
 ===================
 and                 * or min
 or                      max or saturating +
 xor                  modular +


wouldn't it be nice to include such things as

  nand
  nor

given their real world importance?

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Nov 01 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
Let me join the current meeting of the bool gang, guys... ;)

(However, also let me thank Walter for at least the bit --> bool
alias thing. This makes inconsistent code at least syntactically
close to the right thing...)

Sz.

"Juan C" <Juan_member pathlink.com> wrote in message
news:bo0nv2$6vp$1 digitaldaemon.com...

 Indeed, booleans are _not_ numbers, they're _booleans_ there should be no
 implicit conversions in either direction. The common use of the symbols "0" and
 "1" to indicate the boolean values is not to be taken as anything but a
 convenience, which is why we as nerds usually use "false" and "true".

 Boolean should be strongly typed and I don't care about how it is represented
 behind the scenes. If you also want a one-bit number (whatever that's worth)
 then you have the bit. But a bit is _not_ a boolean!

 In article <3FA3964B.1881EEC7 chello.at>, Helmut Leitner says...

"Sean L. Palmer" wrote:

 Boolean algebra is a distinct and separate algebra from real or integer
 algebras.  It supports a much smaller set of operations and possible values.
 I guess the closest numeric representation would be a modulo-2 integer
 arithmetic.  And while I would ordinarily want D to as much as possible
 allow us as users to create such low-level types ourselves, this still falls
 into the category of "everyone will want it", and it's a good idea to
 standardize such a thing before too many incompatible implementations are
 created.

 Boolean            Numeric Equivalent
 ===================
 and                 * or min
 or                      max or saturating +
 xor                  modular +
Nov 01 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Yeah, but I couldn't think of anything in integer arithmetic to correspond
to those!  ;)

I refer the interested reader to a more respectable authority on the
subject:

http://mathworld.wolfram.com/BooleanFunction.html

http://mathworld.wolfram.com/BooleanAlgebra.html

This blurb emphasises the importance of NAND:

"The NAND operation is the basic logical operation performed by the
solid-state transistors ("NAND gates") that underlie virtually all
integrated circuits and modern computers. The first axiom system based on
NAND was given by Henry Sheffer in 1913. In their landmark tome, Whitehead
and Russell (1927) promoted NAND as the appropriate foundation for axiomatic
logic. "


I know that personally I find (A AND B) and (A AND NOT B) very useful for
dealing with masks.  The closest integer operation to this would be
saturating subtraction.  In my day-to-day work I rarely feel the need for
NAND though.

const uint Rmask = 0x000000FF;
const uint Gmask = 0x0000FF00;
const uint Bmask = 0x00FF0000;
const uint Amask = 0xFF000000;

const uint Rshift = 0;
const uint Gshift = 8;
const uint Bshift = 16;
const uint Ashift = 24;

uint RGBA(ubyte r,ubyte g,ubyte b,ubyte a)
{
    return (r << Rshift) | (g << Gshift) | (b << Bshift) | (a << Ashift);
}

uint SetR(uint color, ubyte newR)
{
    return (color & ~Rmask) | (r << Rshift);
}
uint SetG(uint color, ubyte newG)
{
    return (color & ~Gmask) | (r << Gshift);
}
uint SetB(uint color, ubyte newB)
{
    return (color & ~Bmask) | (r << Bshift);
}
uint SetA(uint color, ubyte newA)
{
    return (color & ~Amask) | (r << Ashift);
}

Sean

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3FA3964B.1881EEC7 chello.at...

 "Sean L. Palmer" wrote:

 Boolean algebra is a distinct and separate algebra from real or integer
 algebras.  It supports a much smaller set of operations and possible




values.

 I guess the closest numeric representation would be a modulo-2 integer
 arithmetic.  And while I would ordinarily want D to as much as possible
 allow us as users to create such low-level types ourselves, this still




falls

 into the category of "everyone will want it", and it's a good idea to
 standardize such a thing before too many incompatible implementations




are

 created.

 Boolean            Numeric Equivalent
 ===================
 and                 * or min
 or                      max or saturating +
 xor                  modular +


 wouldn't it be nice to include such things as

   nand
   nor

 given their real world importance?
Nov 01 2003
prev sibling next sibling parent w <w_member pathlink.com> writes:
Fine.
Sep 09 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew Wilson wrote:


 I personally think that bool should be a distinct type, of the size of int,
 and which cannot engage in implicit conversions to and from integer types.
 Sadly, my sway is marginal, at best. :(


Do you really need to unfold a discussion again? This will lead nowhere. 
  An alias does the job.

Besides, people shall want to have an array of boolean, and will want to 
behave like a bitarray, or rather like an array of flags! Bit and bool 
should be the same. Divorcing them will also introduce a tiny but 
unrequiered conceptual complexity into the language, and will open a 
great deal of other questions, as to what conversion rules should be! 
It's like touching a wesp nest.

After all, there are so many *important* issues! We even have a faulty 
division operator, a falty switch, and a ton of other faulty C 
leftovers, which shall not further be dealt with, for obvious reasons. 
And the bool question has long reached a fragile consensus.

-eye
Nov 02 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Well, firstly, my post was a long time ago. Several weeks at least

Second, implicit conversions to/from numeric and non-numeric types is a
flaw, just as much as switch, etc. Just because a majority of people think
that ease of coding is more important than correctness and maintainability,
does not mean the issue is moot, merely boring and unpopular.


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bo31b9$a7o$1 digitaldaemon.com...

 Matthew Wilson wrote:


 I personally think that bool should be a distinct type, of the size of




int,

 and which cannot engage in implicit conversions to and from integer




types.

 Sadly, my sway is marginal, at best. :(


 Do you really need to unfold a discussion again? This will lead nowhere.
   An alias does the job.

 Besides, people shall want to have an array of boolean, and will want to
 behave like a bitarray, or rather like an array of flags! Bit and bool
 should be the same. Divorcing them will also introduce a tiny but
 unrequiered conceptual complexity into the language, and will open a
 great deal of other questions, as to what conversion rules should be!
 It's like touching a wesp nest.

 After all, there are so many *important* issues! We even have a faulty
 division operator, a falty switch, and a ton of other faulty C
 leftovers, which shall not further be dealt with, for obvious reasons.
 And the bool question has long reached a fragile consensus.

 -eye
Nov 02 2003
parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <bo39ao$m2h$1 digitaldaemon.com>, Matthew Wilson says...

Well, firstly, my post was a long time ago. Several weeks at least

Second, implicit conversions to/from numeric and non-numeric types is a
flaw, just as much as switch, etc. Just because a majority of people think
that ease of coding is more important than correctness and maintainability,
does not mean the issue is moot, merely boring and unpopular.


I agree. Completely.
Can we add a page on the D Wiki for the "boolean != bit" party? This issue comes
back every one-two months, and always the same things are said about it. A big
summary of "bool != bit" advantages can be set up, so that the misbeliving can
be redirected there for more information.

I have another proposal:
All D standard libraries should use the standard alias "bool" every time a truth
value is handled. This will ease the bit -> bool conversion when is eventually
done.

Ciao
Nov 04 2003
next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 I agree. Completely.


You are a man of singular wisdom. ;)
Nov 04 2003
prev sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
Roberto Mariottini wrote:

 
 In article <bo39ao$m2h$1 digitaldaemon.com>, Matthew Wilson says...

Well, firstly, my post was a long time ago. Several weeks at least

Second, implicit conversions to/from numeric and non-numeric types is a
flaw, just as much as switch, etc. Just because a majority of people think
that ease of coding is more important than correctness and maintainability,
does not mean the issue is moot, merely boring and unpopular.


 
 I agree. Completely.
 Can we add a page on the D Wiki for the "boolean != bit" party? 


Here it is:
   http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit


 This issue comes
 back every one-two months, and always the same things are said about it. A big
 summary of "bool != bit" advantages can be set up, so that the misbeliving can
 be redirected there for more information.


-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Nov 04 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3FA77603.6E09CC95 hls.via.at...


 Can we add a page on the D Wiki for the "boolean != bit" party?


 Here it is:
    http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit




Cool!

I put some stupid preliminary stuff there, please delete! ;)

[This Wikiing is real fun indeed.. I've done that now for the
first time. Hope the server survived my 20-something consecutive
updates... ;)]

Cheers,
Sz.
Nov 04 2003
parent Helmut Leitner <helmut.leitner wikiservice.at> writes:
Luna Kid wrote:

 Can we add a page on the D Wiki for the "boolean != bit" party?


 Here it is:
    http://www.prowiki.org/wiki4d/wiki.cgi?BooleanNotEquBit


 
 Cool!
 
 I put some stupid preliminary stuff there, please delete! ;)
 
 [This Wikiing is real fun indeed.. I've done that now for the
 first time. Hope the server survived my 20-something consecutive
 updates... ;)]


Now I know why my server was green in the face and wouldn't
speak to me that morning... :-)

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Nov 05 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
So just say that bool/bit store as one machine word, which contains up to 32
or so bools in the same word.  That takes care of storage.  As Walter knows,
a bit* is a regular pointer plus as many bits as are required to address the
number of bits in a machine word., log2(n), as is a reference to bit.  This
is one of the reasons you cannot assume a pointer to be castable back and
forth between int and pointer types without losing information  The bit
itself is either 0 or 1 and always lives in an addressible hardware bit
somewhere, either a cpu flag or memory location.

Conversion from bit to larger types it seems should be possible, but not
implicitly?  Maybe it should act more like a boolean and less like a 1-bit
integer.  If you want to do integer math on a bit, cast to int (0 or 1) or
uint (0 or ~0/) and maybe explicitly specify the true and false results.
Maybe the ? : operator could be the only way to convert a bit to an integer,
and compilers expected to "figure out" how to do things like (a < b) ? -1 :
0 as efficiently as possible (use setlt, decrement).

I'm for rationals as the result of integer division, the rationals being
implicitly convertible to int and return the int portion of the result of
the division operation.

Sean



"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bo31b9$a7o$1 digitaldaemon.com...

 Matthew Wilson wrote:


 I personally think that bool should be a distinct type, of the size of




int,

 and which cannot engage in implicit conversions to and from integer




types.

 Sadly, my sway is marginal, at best. :(


 Do you really need to unfold a discussion again? This will lead nowhere.
   An alias does the job.

 Besides, people shall want to have an array of boolean, and will want to
 behave like a bitarray, or rather like an array of flags! Bit and bool
 should be the same. Divorcing them will also introduce a tiny but
 unrequiered conceptual complexity into the language, and will open a
 great deal of other questions, as to what conversion rules should be!
 It's like touching a wesp nest.

 After all, there are so many *important* issues! We even have a faulty
 division operator, a falty switch, and a ton of other faulty C
 leftovers, which shall not further be dealt with, for obvious reasons.
 And the bool question has long reached a fragile consensus.

 -eye
Nov 03 2003