The lack of a boolean data type in C

[KimmoA]

First of all: I love C and think that it's beautiful. However, there is
at least one MAJOR flaw: the lack of a boolean type.

OK. Some of you might refer to C99 and its _Bool (what's up with the
uppercase 'B' anyway?) and the header you can include (apparently) to
get a real "bool". This isn't my point, however -- it should have been
there from the beginning.

char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong, and I think that most of you agree. Plus, it's
still too large.

"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools. But an int is a very large data type for something that will
only ever be true or false (1 or 0). This really, really bugs me.

Why, back when C was designed, didn't they see a reason to build in a
boolean type into the language? Now it matters less, I guess, but back
then, there should have been very strong technical reasons. It just
doesn't make any sense whatsoever to me.

I have asked many people about this for quite some time, and they are
all just telling me that I'm silly for bringing it up. Why? It's not
that I NEED a bool to get anything done -- it's the principle. Saving
resources and coding a little more prettily is a Good Thing (TM) IMO.

So... can somebody properly explain this to me once and for all? I'm
sure there MUST be a logical explanation that nobody seems to really
understand. The madness must end.

bool some_bool = 0; /* How great it would be... */

[Default User]

Ian Collins wrote:

Default User wrote:

Ian Collins wrote:

Given a bool type, you can specialise or optimise operations or
constructs for that specific type, which you can't do with a user
defined equivalent.

True, but not what the OP was belly-aching about. He thinks a
defined type would save storage (char is still too big in his
estimation), and that's unlikely.

I was thinking of the way C++ specialises vector<boolas a compact
vector of bits, which does save on storage. C could do this for
arrays of _Bool, but it would break too many addressing rules to be
viable.

And you can do it in C if that's desired, as mentioned elsewhere, with
bit arrays and few access macros.


Brian

[Richard Heathfield]

jacob navia said:

<snip>

The "macro" approach hides the
intention of the programmer behind a lot of shifts and
masks AND operations,

Not at all. The names I chose for my macros make it perfectly clear what
they do.

making it impossible for the compiler
to do any optimizations specifically designed for bit arrays.

So what? If ever it becomes a performance problem, I'll worry about it.
Until then, I'll write the code to be clear to a human reader, and let the
compiler worry about how best to optimise it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:
[...]

>> #define false 0
#define true 1
typedef int bool;

[...]
Rather than the above, have you considered:
typedef enum { false, true } bool;
? It's very nearly equivalent, but I find it a bit better
esthetically.

"Aesthetically."

Both spellings are acceptable, but it looks like "aesthetically" is
preferred (at least according to Merriam Webster).

I once ran across this gem:

typedef enum { TRUE, FALSE } bool;

No foolin', I really did!

Ick!

Well, I suppose you could make that work if you're *really* careful
(which means avoiding idiomatic C in many cases).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Arthur J. O'Dwyer]

On Thu, 21 Dec 2006, Richard Heathfield wrote:

jacob navia said:
<snip>

>The "macro" approach hides the
intention of the programmer behind a lot of shifts and
masks AND operations,

Not at all. The names I chose for my macros make it perfectly clear what
they do.

>making it impossible for the compiler
to do any optimizations specifically designed for bit arrays.

So what? If ever it becomes a performance problem, I'll worry about it.
Until then, I'll write the code to be clear to a human reader, and let the
compiler worry about how best to optimise it.

And FWIW, compilers are really smart. I'm biased,[1] but I assure you
that if the compiler has /any/ "optimizations specifically designed for
bit arrays", it will go out of its way to find (x = x&~m|y&m), even
hidden behind a macro, and make the obvious substitution.

-Arthur

[1] - working as I do, now, with an optimizing compiler for compiling
embedded software that's just packed with bitfield operations
(pun intended). I honestly have no idea whether GCC on x86 is anywhere
close to Green Hills on PowerPC in terms of bitfield ops.

[Keith Thompson]

"KimmoA" <ki****@gmail.comwrites:

Keith Thompson wrote:

[...]

>There are other languages that *have* had a Boolean type from their
beginnings.

I know what you mean by this. You want me to switch to a different
language for questioning one single thing. That's silly, and there is
no other language that I'm even remotely interested in. I switched FROM
C++ to C, but at least C++ had the bool...

No, I'm not encouraging you to switch languages.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Heathfield a écrit :

>KimmoA said:

>>>Keith Thompson wrote:
>It's the principle.

What principle?

That it makes sense to have a boolean type? I still want to know what
you all use instead...

If I need one, I use an int. Who cares about the storage cost of one
lousy int? And if I need loads, I use an array of unsigned char and
some bit macros. One bit per bool.
<snip>

There are many processors with specialized bit shifting or
bit extracting instructions. The "macro" approach hides the
intention of the programmer behind a lot of shifts and
masks AND operations, making it impossible for the compiler
to do any optimizations specifically designed for bit arrays.

I don't see why a sufficiently clever optimizer couldn't translate
code using shifts and masks into code using some machine-specific bit
extraction instruction -- assuming the resulting code is actually
better than shifting and masking.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Charlton Wilbur <cw*****@chromatico.netwrites:

>>>>>"KA" == KimmoA <ki****@gmail.comwrites:

KAThat it makes sense to have a boolean type? I still want to
KAknow what you all use instead...

Integers.

KAObviously I realize that nothing can be done about it now, but
KAI want to fully understand why they decided to design the
KAlanguage this way. So far, nobody has really told me anything
KAthat truly convinces me that it made sense.

Because the only advantage is theoretical.

Imagine that you have a bool type. It's either an int or char with
syntactic sugar imposing constraints on its behavior, or it's a single
bit which needs to be extracted. The former gives you no real
advantage over what the language offers now, plus a whole lot of
potential for confusion, and the latter is likely to trade off speed
for theoretical purity.

Because it can't be predictably translated into machine code.

Why is that a problem? I don't care what the machine code looks like,
as long as it implements the semantics correctly; efficiency is a
secondary concern, but I *still* don't usually care about the specific
instruction sequences.

Microprocessors understand integers and floating-point numbers at a
very low level, but most often implement boolean as equal to zero or
not equal to zero. The C approach to Boolean math -- that zero is
false and non-zero is true -- maps directly to this approach. Adding
the conceit of Boolean variables to the language would either map
directly to this, giving the programmer no real advantage over using
integral types in the first place, or map to the extracting-bits approach.

In short: the benefit you get from a pure Boolean type is nonexistent.
That's why it's not in C. You have yet to show any compelling reason
to include it.

But C99 does have _Bool.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"KimmoA" <ki****@gmail.comwrites:

Keith Thompson wrote:

It's the principle.

What principle?

That it makes sense to have a boolean type? I still want to know what
you all use instead...

>You want C to have had a built-in Boolean type from the beginning.
It didn't. I'm afrid there's really nothing we can do about that
beyond offering a very limited amount of sympathy.

Obviously I realize that nothing can be done about it now, but I want
to fully understand why they decided to design the language this way.
So far, nobody has really told me anything that truly convinces me that
it made sense.

It's because Dennis Ritchie wanted it that way.

At the time, it simply wasn't felt that it was necessary. C has the
convention that any scalar expression can be used as a condition (in
an if or while statement, or as an operand of "!", "||", or "&&"). If
the expression has the value zero, it's treated as false; if it has
any non-zero value, it's treated as true.

Given these conventions, a separate Boolean type simply is not needed.
In fact, C programmers have been writing code for decades without the
need for such a type. C is intended to be a relatively small
language. If you want a variable to hold a condition, just use an
int. For example:

int done = 0;
while (!done) {
...
if (...) {
done = 1;
}
...
}

You have to be careful about some things. For example this:

cond = isdigit(c);
if (cond == 1) {
...
}

is incorrect, because isdigit doesn't necessary return 0 or 1. But this:

cond = isidigit(c);
if (cond) {
...
}

is both correct and better stylistically.

As for storage size concerns, that's already been explained several
times. Storing a single Boolean object in a single bit is not
helpful; the rest of the byte or word containing that bit isn't going
to be used for anything anyway, the code to extract that single bit is
probably larger than the code to load a byte or word, and you wouldn't
be able to take the object's address. If you want large arrays of
booleans, large enough that storage size becomes a concern, you may
want to trade off code complexity against data size and use a packed
bit array. C has no syntax for doing this directly; apparently
there's never been enough of a demand for it to justify adding it to
the language. But again, this is something that can already be
implemented in the language itself.

Of course that's not the whole story. A *lot* of programmers have
implemented their own Boolean types, by various names and with various
definitions. See section 9 of the comp.lang.c FAQ,
<http://www.c-faq.com/>, for some examples. The problem with that is
that types defined by different programmers may not be compatible, and
when their code is combined into a single program, it has to be
reconciled somehow. C99 added _Bool and <stdbool.hto bring some
order to the situation *without* breaking any existing solutions.

None of this implies that C *couldn't* have had a built-in Boolean
type from the beginning. It easily could have. Maybe it even would
have been better if it had. C, like any language, was designed by
imperfect human beings (mostly by one particular human being). If you
don't agree with the decisions, that's fine, but there were valid
reasons.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Yevgen Muntyan]

Ian Collins wrote:

Default User wrote:

>>Ian Collins wrote:

>>>Default User wrote:
KimmoA wrote:


>Richard Bos wrote:
>
>
>
>>Too large? How many of these do you want? Thousands?
>
>It's the principle.
It's a silly one though. Even languages with built-in boolean types
are likely to have it be some machine-adressable type. You aren't
guaranteed to have it smaller than a char, and if fact seldom will.
Given a bool type, you can specialise or optimise operations or
constructs for that specific type, which you can't do with a user
defined equivalent.

True, but not what the OP was belly-aching about. He thinks a defined
type would save storage (char is still too big in his estimation), and
that's unlikely.

I was thinking of the way C++ specialises vector<boolas a compact
vector of bits, which does save on storage. C could do this for arrays
of _Bool, but it would break too many addressing rules to be viable.

See http://www.gotw.ca/publications/N1211.pdf or just google for
vector<bool>.

Regards,
Yevgen

[Eric Sosman]

Keith Thompson wrote:

[...] C has the
convention that any scalar expression can be used as a condition (in
an if or while statement, or as an operand of "!", "||", or "&&"). If
the expression has the value zero, it's treated as false; if it has
any non-zero value, it's treated as true.

Given these conventions, a separate Boolean type simply is not needed.
[...]

At some risk to topicality (but we're already discussing
"What-If C" anyhow), I'll mention that there's at least one
other popular language that gets along quite well without a
Boolean type, thank you very much. I refer to Lisp, in which
the value `nil' (roughly meaning "no value") is considered
false, while any non-`nil' ("any actual value") is true.

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

Default User wrote:

Ian Collins wrote:

>Default User wrote:

>>Ian Collins wrote:

>>>Given a bool type, you can specialise or optimise operations or
constructs for that specific type, which you can't do with a
user defined equivalent.

True, but not what the OP was belly-aching about. He thinks a
defined type would save storage (char is still too big in his
estimation), and that's unlikely.

I was thinking of the way C++ specialises vector<boolas a
compact vector of bits, which does save on storage. C could do
this for arrays of _Bool, but it would break too many addressing
rules to be viable.

And you can do it in C if that's desired, as mentioned elsewhere,
with bit arrays and few access macros.

In Pascal you just use a set. You might need an array of sets to
mimic lots and lots of booleans.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
Of course that's not the whole story. A *lot* of programmers have
implemented their own Boolean types, by various names and with
various definitions. See section 9 of the comp.lang.c FAQ,
<http://www.c-faq.com/>, for some examples. The problem with that
is that types defined by different programmers may not be
compatible, and when their code is combined into a single program,
it has to be reconciled somehow. C99 added _Bool and <stdbool.h>
to bring some order to the situation *without* breaking any
existing solutions.

Which is why I wrote stdops.h (elsethread) as I did, to port those
same standards to C90.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Malcolm]

"Keith Thompson" <ks***@mib.orgwrote in message

Charlton Wilbur <cw*****@chromatico.netwrites:

>Imagine that you have a bool type. It's either an int or char with
syntactic sugar imposing constraints on its behavior, or it's a single
bit which needs to be extracted. The former gives you no real
advantage over what the language offers now, plus a whole lot of
potential for confusion, and the latter is likely to trade off speed
for theoretical purity.

Because it can't be predictably translated into machine code.

Why is that a problem? I don't care what the machine code looks like,
as long as it implements the semantics correctly; efficiency is a
secondary concern, but I *still* don't usually care about the specific
instruction sequences.

A lot of C has to integrate with functions written in assembly. The fewer
hassles because datatypes have different storage depending on context the
better.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrites:

Keith Thompson wrote:

>[...] C has the
convention that any scalar expression can be used as a condition (in
an if or while statement, or as an operand of "!", "||", or "&&"). If
the expression has the value zero, it's treated as false; if it has
any non-zero value, it's treated as true.
Given these conventions, a separate Boolean type simply is not
needed.
[...]

At some risk to topicality (but we're already discussing
"What-If C" anyhow), I'll mention that there's at least one
other popular language that gets along quite well without a
Boolean type, thank you very much. I refer to Lisp, in which
the value `nil' (roughly meaning "no value") is considered
false, while any non-`nil' ("any actual value") is true.

If I recall correctly, any non-'nil' value is true, but there is a
special true value called 't'.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Default User wrote:

[...]

>And you can do it in C if that's desired, as mentioned elsewhere,
with bit arrays and few access macros.

In Pascal you just use a set. You might need an array of sets to
mimic lots and lots of booleans.

Or you can use a packed array of boolean. ("Packed" is standard,
right?) But sets do give you some handy operations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

Charlton Wilbur <cw*****@chromatico.netwrites:

In short: the benefit you get from a pure Boolean type is nonexistent.
That's why it's not in C. You have yet to show any compelling reason
to include it.

But C99 does have _Bool.

True, but I have yet to see any compelling reason to include it. I see
the reasons they had to do so; I don't find them particularly
compelling.

Richard

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

Eric Sosman <es*****@acm-dot-org.invalidwrites:

At some risk to topicality (but we're already discussing
"What-If C" anyhow), I'll mention that there's at least one
other popular language that gets along quite well without a
Boolean type, thank you very much. I refer to Lisp, in which
the value `nil' (roughly meaning "no value") is considered
false, while any non-`nil' ("any actual value") is true.

If I recall correctly, any non-'nil' value is true, but there is a
special true value called 't'.

There is. Almost as in C, in fact: any non-zero value is true, but there
is a special true value called 1. The only difference is that in Lisp,
the special true and false values are not anything else _but_ boolean
values (but non-booleans can be used as booleans, all true), while in C,
the special true and false values are _also_ integers.

Richard

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

Default User wrote:

[...]

>>And you can do it in C if that's desired, as mentioned elsewhere,
with bit arrays and few access macros.

In Pascal you just use a set. You might need an array of sets to
mimic lots and lots of booleans.

Or you can use a packed array of boolean. ("Packed" is standard,
right?) But sets do give you some handy operations.

Yes, but that just indicates a willingness to have storage packed,
it doesn't enforce it. It also means that access requires use of
the standard procedures pack and unpack. Something analagous to
getting the address of a register variable which requires copying
the variable into another one.

The biggest nuisance of sets is that there is no standard way to
determing the value of maxset other than RTFM. The better systems
ensure that a "SET OF char" is possible, but that is not
guaranteed, and there is also no standard way to evaluate
ord(MAXCHAR).

These are areas that C covers very nicely in <limits.h>.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Eric Sosman]

Richard Bos wrote:

Keith Thompson <ks***@mib.orgwrote:

>Eric Sosman <es*****@acm-dot-org.invalidwrites:

>> At some risk to topicality (but we're already discussing
"What-If C" anyhow), I'll mention that there's at least one
other popular language that gets along quite well without a
Boolean type, thank you very much. I refer to Lisp, in which
the value `nil' (roughly meaning "no value") is considered
false, while any non-`nil' ("any actual value") is true.

If I recall correctly, any non-'nil' value is true, but there is a
special true value called 't'.

There's nothing special about `t': it's just a non-`nil'
atom. In a "pure Boolean" situation where true/false is all
that matters and there's no additional information to impart,
the convention is to use `t' -- but it's just a convention,
like C's use of 1 when -42 would do; both are "true."

There is. Almost as in C, in fact: any non-zero value is true, but there
is a special true value called 1. The only difference is that in Lisp,
the special true and false values are not anything else _but_ boolean
values (but non-booleans can be used as booleans, all true), while in C,
the special true and false values are _also_ integers.

That's not right (or perhaps I've misunderstood you). The
value `nil' has meanings other than "false:" it also means "empty
list" and "no matching key in hash table" and "no more input" and
so on -- very roughly speaking, it has all the meanings C associates
with NULL (including "false") and with EOF.

The atom `t' is conventionally used for "true" when there's
nothing else of interest lying around, but it is in no way special
or devoted to Boolean uses only. The program is free to use `t'
in all the ways it could use other atoms like `a' and `x' and
`xyzzy'.

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob navia]

Arthur J. O'Dwyer a écrit :

>
On Thu, 21 Dec 2006, Richard Heathfield wrote:

>jacob navia said:
<snip>

>>The "macro" approach hides the
intention of the programmer behind a lot of shifts and
masks AND operations,

Not at all. The names I chose for my macros make it perfectly clear what
they do.

>>making it impossible for the compiler
to do any optimizations specifically designed for bit arrays.

So what? If ever it becomes a performance problem, I'll worry about it.
Until then, I'll write the code to be clear to a human reader, and let
the
compiler worry about how best to optimise it.

And FWIW, compilers are really smart. I'm biased,[1] but I assure you
that if the compiler has /any/ "optimizations specifically designed for
bit arrays", it will go out of its way to find (x = x&~m|y&m), even
hidden behind a macro, and make the obvious substitution.

-Arthur

[1] - working as I do, now, with an optimizing compiler for compiling
embedded software that's just packed with bitfield operations
(pun intended). I honestly have no idea whether GCC on x86 is anywhere
close to Green Hills on PowerPC in terms of bitfield ops.

Well I am porting to PowerPc lcc-win32. I have a working first version
and I am discovering the bitfield operations in that CPU.

I do not want to make the compiler overly complex. Green Hills has
probably a lot of code to discover those bitfield-extracting operations
from a series of ANDs and masking etc... Besides having somewhere
make a wrong "discovery" it is incredibly easy.

If we had true boolean arrays we could do that without making C
compilers more commplex taht they need to be.

jacob

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

Default User wrote:

[...]

>>>And you can do it in C if that's desired, as mentioned elsewhere,
with bit arrays and few access macros.

In Pascal you just use a set. You might need an array of sets to
mimic lots and lots of booleans.

Or you can use a packed array of boolean. ("Packed" is standard,
right?) But sets do give you some handy operations.

Yes, but that just indicates a willingness to have storage packed,
it doesn't enforce it. It also means that access requires use of
the standard procedures pack and unpack. Something analagous to
getting the address of a register variable which requires copying
the variable into another one.

[...]

At least in the (non-standard) versions of Pascal I've used, "pack"
and "unpack" weren't necessary. You could do something like this:

Vec: packed array(1 .. 100) of Boolean;
...
Vec[50] = True;
if Vec[50] then
...

and compiler would generate whatever code is necessary to get it
right. Pascal doesn't define array indexing in terms of pointer
artithmetic; in fact, it doesn't define pointer arithmetic.

(I claim this is marginally topical as a comparison to what C *could*
have defined, but didn't.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Arthur J. O'Dwyer]

On Fri, 22 Dec 2006, jacob navia wrote:

Arthur J. O'Dwyer a écrit :

>On Thu, 21 Dec 2006, Richard Heathfield wrote:

>>jacob navia said:

[re: macros with << and & for bit array operations]

>>>making it impossible for the compiler
to do any optimizations specifically designed for bit arrays.

So what? If ever it becomes a performance problem, I'll worry about it.
Until then, I'll write the code to be clear to a human reader, and let the
compiler worry about how best to optimise it.

And FWIW, compilers are really smart. I'm biased,[1] but I assure you
that if the compiler has /any/ "optimizations specifically designed for
bit arrays", it will go out of its way to find (x = x&~m|y&m), even
hidden behind a macro, and make the obvious substitution.

-Arthur

[1] - working as I do, now, with an optimizing compiler for compiling
embedded software that's just packed with bitfield operations
(pun intended). I honestly have no idea whether GCC on x86 is anywhere
close to Green Hills on PowerPC in terms of bitfield ops.

Well I am porting to PowerPc lcc-win32. I have a working first version
and I am discovering the bitfield operations in that CPU.

Yeah. I like "rlwimi". ;)

I do not want to make the compiler overly complex. Green Hills has
probably a lot of code to discover those bitfield-extracting operations
from a series of ANDs and masking etc... Besides having somewhere
make a wrong "discovery" it is incredibly easy.

If we had true boolean arrays we could do that without making C
compilers more commplex taht they need to be.

Unoptimizing compilers, sure. I totally agree that the more low-level
constructs a language provides natively, the better the code generated
by a stupid compiler can be.
However, in the Real World(tm), people are often (usually?) stupider
than their compilers, and even if C did provide bit-array operations
natively, there would be some poor fool[1] writing

#define FLAG1 0x20
x &= ~FLAG1;

and then wondering why his compiler doesn't use the "bclri" machine
instruction. So an optimizing compiler would still have to support both
methods: C's old bit flags and our new bit-array primitives. Ick.

my $.02,
-Arthur

[1] - Seen in someone else's code a while back:
/* Fill x with copies of the sign bit */
x |= x >1;
x |= x >2;
x |= x >4;
x |= x >8;
x |= x >16;
Go ahead, optimize /that/!
And for the C gurus: What's the cleanest way to do what that
programmer was doing, but still in standard C? The obvious solution,
x >>= 31;
isn't guaranteed to work for signed numbers.

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*******@andrew.cmu.eduwrites:
[...]

[1] - Seen in someone else's code a while back:
/* Fill x with copies of the sign bit */
x |= x >1;
x |= x >2;
x |= x >4;
x |= x >8;
x |= x >16;
Go ahead, optimize /that/!
And for the C gurus: What's the cleanest way to do what that
programmer was doing, but still in standard C? The obvious solution,
x >>= 31;
isn't guaranteed to work for signed numbers.

Assuming the comment is correct:

if (x < 0) {
x = INT_MIN;
}
else {
x = 0;
}

substituting the proper constant for INT_MIN.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Denis Kasak]

KimmoA wrote:

>
Well... even if it's entirely pointless, being able to tell to the
compiler that a variable can only ever be "on" or "off" would feel so
much better. Nobody else seems to care, though... Hmpf.

Why would you want to do something that would save neither data nor
execution time (or be of any use at all, for that matter)?

Have you understood that, as others have already pointed out, even the
compiler cannot implement the bool type 'natively'? It still has to
emulate it either by typedef'ing it to another type or by packing bools
into a bigger type. This is a limitation of the processor and/or memory.
In order to implement a truly 'native' Boolean type, your architecture
would need to be able to address each bit without any additional
overhead (without offsets, masking, etc). This is, of course, very
cumbersome to do as it would require fundamental changes in today's
computer architectures, all for little or no realistic gain.

As for your 'feels right' point, what's wrong with #include <stdbool.h>
or, if you don't have access to a compiler that supports _Bool, with
typedef'ing enum to bool?

--
Denis Kasak

[Richard]

jaysome <ja*****@hotmail.comwrites:

On 20 Dec 2006 00:51:49 -0800, "Harald van D?k" <tr*****@gmail.com>
wrote:

>>Richard Heathfield wrote:

>>jaysome said:
My "workaround" has always been:

typedef unsigned char boolean;
#define FALSE 0
#define TRUE 1

This allows you to use these types of statments:

boolean oven_is_on;
oven_is_on = FALSE;
oven_is_on = TRUE;
if ( oven_is_on )
if ( !oven_is_on )
char *OVEN_STRINGS[2] = {"OFF", "ON"};
printf("Oven is %s\n", OVEN_STRINGS[oven_is_on]);

But your OVEN_STRINGS argument to printf is not defined.

The code is probably intended as a series of fragments, but ignoring
that, since you did too:

Yes, fragments.

>>Firstly, there is no argument to printf. There is a syntax error.

Huh?

The prototype for printf() is:

int printf(const char *format, ...);

How is the above a syntax error?

They are picking holes : you should have specifically said that the code
was a non compilable example of how you tend to use your boolean types
to index into an array of text representations for on & off. Even then
someone would probably have told you off : don't worry - it's typical
nit picking anal retentiveness. It was fairly obvious to anyone who read
that far down the thread what you meant.

[Chris Hills]

In article <em**********@news1.xnet.hr>, Denis Kasak
<de*********@gmail.comwrites

>KimmoA wrote:

> Well... even if it's entirely pointless, being able to tell to the
compiler that a variable can only ever be "on" or "off" would feel so
much better. Nobody else seems to care, though... Hmpf.

Why would you want to do something that would save neither data nor
execution time (or be of any use at all, for that matter)?

Have you understood that, as others have already pointed out, even the
compiler cannot implement the bool type 'natively'? It still has to
emulate it either by typedef'ing it to another type or by packing bools
into a bigger type. This is a limitation of the processor and/or
memory. In order to implement a truly 'native' Boolean type, your
architecture would need to be able to address each bit without any
additional overhead (without offsets, masking, etc). This is, of
course, very cumbersome to do as it would require fundamental changes
in today's computer architectures, all for little or no realistic gain.

As it happens the worlds most common MCU does have bit addressable
memory and bit types. That aside the rest of your argument holds true
as most MCU /CPU don't have bit addressable memory

Because of this there are such things as signed and unsigned bit
types... IT the Bit type is in a larger memory type and therefore can
have a sign bit.

>As for your 'feels right' point, what's wrong with #include <stdbool.h>
or, if you don't have access to a compiler that supports _Bool, with
typedef'ing enum to bool?

Sounds sensible to me,
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Malcolm McLean]

"Chris Hills" <ch***@phaedsys.orgwrote

Because of this there are such things as signed and unsigned bit types...
IT the Bit type is in a larger memory type and therefore can have a sign
bit.

That's an important philsophical issue.
In a set bit the msb is set, so in two's complement notation it is -1.