Absense of bool

[AommiK]

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... */

 

[Malcolm McLean]

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.

C is portable assembly. Generally there is no way of manipulating single
bits with assembly instructions, though of course you can do so with a
combination of instructions.
So bool wasn't included.
We've moved on a little since, and there is quite a good case for it, since
it doucments that a variable is flag, and that is frequently what we want.

 

[santosh]

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.

At best this is a minor irritation, not a major flaw IMHO.

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.

It was not a badly felt need during much of C's evolution and still is
not.

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.

Use bitfields.

"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.

Because bool is too often an overrated type. In anycase with most
machines bool is simulated by either a byte of a packed type.

If you're bothered about space why not use bitfields?

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.

This can be done. It wasn't important enough to be Standardised.

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

You can do this since C99.

 

[James Kuyper]

AommiK wrote:
....

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

The committee chose a name that is reserved to the implementation for
ALL uses, in order to avoid breaking any code that currently defined
'bool' with a conflicting meaning. They couldn't use _bool, either,
because that name is reserved only " for use as identifiers with file
scope in both the ordinary and tag name spaces."

 

[J. J. Farrell]

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.

Why is that a MAJOR flaw? I have trouble seeing it as even a minor
flaw.

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.
Why?

Char is a small int. We all know that. However, "char some_bool = 0;"
simply feels wrong,
Why?

and I think that most of you agree.

I doubt that very much.

Plus, it's still too large.

It's typically the smallest addressable type. If you want smaller
(with the added overhead of more code to implement it) use a bit
field.

"int some_bool = 0;" is what I -- and everyone else, I assume -- use
for bools.

Why do you assume that?

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?

That's a very silly question. They didn't see a need for it because
they didn't see a need for it. You need to explain why you think they
should have seen a need for it.

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.

A value of zero is false, non-zero is true. Why do you need a
particular type to hold the value?

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?

You're not necessarily silly for bringing it up, but you're doing it
in a silly way. You need to explain why you think it was needed, and
why anyone should have seen a need for it. You seem to assume that
everyone shares your view of C and its history and agrees with you for
some reason.

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.

How would it save resources? A boolean type smaller than char would
require more resources to implement and at run time. How would it make
coding any prettier?

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.

I've no idea what you're talking about.

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

It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?

 

[Keith Thompson]

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.

[...]

On typical systems, allocating 8 or more bits to an object intended
only to hold the values 0 and actually saves space. Accessing a
single bit, without disturbing the rest of the byte or word that it's
a part of, is more expensive than accessing the entire byte or word.
Most CPUs can't directly address single bits.

 

[Keith Thompson]

It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?

Documentation.

 

[Eric Sosman]

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.

It's probably this "MAJOR" flaw that has kept C on the
sidelines and prevented it from gaining any noticeable following.

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.

If you'll spend several dozens of hours and many thousands
of dollars to lie on a couch and chat with a professional about
your dreams and your early childhood memories, your obsession
may turn out to be curable.

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 sympathize. For me, the thing that makes no sense whatsoever
is quantum entanglement. However, the fact that it makes no sense
to me doesn't impel me to the belief that QE is a "MAJOR" flaw in
Nature. You seem to attach more importance to your own befuddlement
than I do to mine.

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.

Kidding aside, there's the crux: You declare that you do not
need a Boolean type "to get anything done."

Say your words over again, slowly: You claim you

DO

NOT

NEED

a Boolean type. Why, then, is C deficient in a "MAJOR" way for
lacking what you DO. NOT. NEED? C also lacks quaternions, nested
functions, three-way ifs, and the kitchen sink -- "MAJOR" omissions
all, I guess you'd say, whether you would use them or not.

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.

The "madness," if you choose to think of it that way, ended
eight years ago. Haven't you grown weary of tearing your hair
and rending your clothing? Aren't the sackcloth and ashes
getting a little tiresome? Your stamina is admirable, but ...

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

Go ahead. No one is stopping you, except possibly your peers
in code review who will (1) object to your idiosyncratic way of
spelling `false' and (2) ask what the purpose of `some_bool' is.
In my experience, programs in all programming languages use Boolean
*values* all the time, but the use of Boolean *variables* is far
rarer.

 

[Philip Potter]

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.

Do you have an example of a language with a boolean type which will
store the boolean in a location smaller than a byte?

(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)

I agree that it's useful to have a bool type for code readability
purposes; but you have always been able to typedef one. However I'm just
not convinced that a bool should be stored by default in a single bit,
within a byte shared with other bool values.

 

[Army1987]

(C optimizers are allowed to reduce the size used by bool types; but I
would guess that the performance hit by requiring all those extra
bit-twiddling operations would generally be considered to much.)

They can't. See 6.2.6.1p2.
Also, I must be allowed to access them as arrays of unsigned char,
if several _Bool are stored in the same byte
memset(&bool_var, 0, sizeof bool_var) could affect other ones,
which 6.2.4p2 forbids. Also, if the bytes of an object are
themselves objects, if I do *(unsigned char *)&bool_var = '/';
that byte will stay the same until I access bool_var again (it
could change even if I just *read* it, because '/' could be a
trap representation for _Bool causing UB, but if I don't access it
at all, it can't change).
As I see it, _Bool is required to have at least seven padding
bits. (Anyway, I think that if a _Bool is declared as register, or
if the compiler pretends that it is because its address is never
taken, it might not actually store them anywhere.)

 

[Army1987]

It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?

The fact that the implementation can choose which one it is.
(So can it with enum { false, true }, but the latter in some
implementations turns out to be much larger.)
Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
(_Bool)I are one.

 

[Army1987]

It's there in C99, pretty pointlessly I think. What is the advantage
of this type? What does it buy me over char or int?

The fact that the implementation can choose which one it is.
(So can it with enum { false, true }, but the latter in some
implementations turns out to be much larger.)
Also, (char)0.1 and (int)I are zero, whereas (_Bool)0.1 and
(_Bool)I are one. (But one could simply write
char foo = (bar != 0); so that doesn't buy much...)

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

They can't.

They can for those booleans that never have their address taken.

 

[Richard]

Why is that a MAJOR flaw? I have trouble seeing it as even a minor
flaw.

I see it as a flaw. A minor one. But a flaw nonetheless.

Why?

Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....

Why?

Because it's not a true "boolean". When you see a char its not obvious
fro the type that it's a binary indicator. Fairly obvious I would have
thought.

I doubt that very much.

Lets turn it around. Why would you think having a real boolean is NOT a
good idea?

 

[Philip Potter]

They can for those booleans that never have their address taken.

Yes, I was relying on this and the as-if rule.

 

[J. J. Farrell]

I see it as a flaw. A minor one. But a flaw nonetheless.





Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....





Because it's not a true "boolean". When you see a char its not obvious
fro the type that it's a binary indicator. Fairly obvious I would have
thought.





Lets turn it around. Why would you think having a real boolean is NOT a
good idea?

 

[J. J. Farrell]

Apologies for the previous unedited reply.

I see it as a flaw. A minor one. But a flaw nonetheless.

...

Lets turn it around. Why would you think having a real boolean is NOT a
good idea?

I don't think that, and never suggested that I did. I don't have any
strong feelings on the subject at all. I'm not sure that I consider
it's absence a flaw, but if it is it's a very minor one. I wouldn't
object to its presence; its usefulness might outweigh the complexity
it would add, but by very little. Overall it doesn't much matter
either way in my opinion.

The only real utility I can see in it is self-documentation of code,
but that's easily achieved by a programmer-defined typedef or even by
the name of the variable. It doesn't seem to warrant a fundamental
type.

I'm just puzzled why someone should see its absence as a MAJOR flaw,
to the extent that they can't conceive that the need for it didn't
occur to the inventors of the language. That's why I was asking.

 

[santosh]

Because C is a programming language that applies all sorts of rules on
other types and a C program uses boolean decision making every other
line or so ....

And in C boolean decision making doesn't require a boolean type.

Because it's not a true "boolean".

C defines zero as boolean false and any other value as boolean true, in
a boolean context. A specific boolean type isn't necessary except for
aesthetic purposes.

When you see a char its not obvious
fro the type that it's a binary indicator.

That's what typedefs are for. Also the object's name should convey it's
intended boolean usage.

Fairly obvious I would have thought.

It's also fairly obvious that unlike languages like C#, C doesn't
require a boolean type; any value is interpreted as true or false
according to a simple rule.

Anyway the latest C standard _has_ mandated a boolean type, for whatever
it's worth.

However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.

Now, as far as I can see, there is no readily apparent reason against
implementing a bit type in C. However the fact that C conveniently
treats any integer value as either true or false, when in a boolean
context, combined with the probable loss of execution efficiency in
manipulating a bit type, meant that a specific boolean bit type was not
(and is not) felt as very essential to the language.

Lets turn it around. Why would you think having a real boolean is NOT
a good idea?

No one said it was not a good idea. Probable reasons were supplied for
why it was not built into the language from it's beginning. That does
not imply that boolean types are either good or bad.

 

[Richard]

Apologies for the previous unedited reply.



I don't think that, and never suggested that I did. I don't have any

You seemed a little "anti BOOL" in your previous reply and pretty much
disagreed with the other poster and each point he made for having BOOL
(not that I agreed with his points necessarily either).

strong feelings on the subject at all. I'm not sure that I consider
it's absence a flaw, but if it is it's a very minor one. I wouldn't
Agreed.

object to its presence; its usefulness might outweigh the complexity
it would add, but by very little. Overall it doesn't much matter
either way in my opinion.

What complexity would you be thinking of?

The only real utility I can see in it is self-documentation of code,
but that's easily achieved by a programmer-defined typedef or even by
the name of the variable. It doesn't seem to warrant a fundamental
type.

I would agree that there's no call for it now since its not there.

I'm just puzzled why someone should see its absence as a MAJOR flaw,
to the extent that they can't conceive that the need for it didn't
occur to the inventors of the language. That's why I was asking.

And I agree with you there. It would be nice though IMO. The underlying
representation should not concern the programmer too much either.

 

[Richard]

And in C boolean decision making doesn't require a boolean type.

Obviously. But that isn't the issue.

C defines zero as boolean false and any other value as boolean true, in
a boolean context. A specific boolean type isn't necessary except for
aesthetic purposes.

Bingo! You've got it. Aesthetic purposes. Also for things like *cough*
variable tagging and debugging it is useful.

That's what typedefs are for. Also the object's name should convey it's
intended boolean usage.

So shall we get rid of ALL types and use typedefs?

It's also fairly obvious that unlike languages like C#, C doesn't
require a boolean type; any value is interpreted as true or false
according to a simple rule.

This is true of ANY language I have dealt with.

if(x) .....

Anyway the latest C standard _has_ mandated a boolean type, for whatever
it's worth.

Aha. So not so silly and "useless" after all?

However the OP was complaining about the lack of single bit boolean
types and the supposed wasted storage by using a char or int or
whatever.

I would agree that is silly.

Now, as far as I can see, there is no readily apparent reason against
implementing a bit type in C. However the fact that C conveniently
treats any integer value as either true or false, when in a boolean
context, combined with the probable loss of execution efficiency in
manipulating a bit type, meant that a specific boolean bit type was not
(and is not) felt as very essential to the language.


No one said it was not a good idea. Probable reasons were supplied for
why it was not built into the language from it's beginning. That does
not imply that boolean types are either good or bad.

It is fairly clear to me that a boolean type would only make code
cleaner. Would I use them? Probably not :-; I'm too entrenched in zero
and non zero.