Absense of bool

[J. J. Farrell]

What complexity would you be thinking of?

Not a big deal, just that it has to be worked out and defined exactly
how it fits into the language, and compilers and libraries then have
to support these things. Can it's address be taken, how does it work
in artithmetic expressions, what formatting character represents it in
sprintf(), should it size relate in any particular way to any other
type, should it generally be optimized for size or speed of access,
and so on. They chose to do this for C99; I don't think I'd have
bothered.

 

[santosh]

Obviously. But that isn't the issue.

However it is one possible reason why C's designers did not consider a
dedicated boolean type as important.

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

You cannot get rid of some types without destroying the core language.
Also note that typedef cannot be used without the presence of at least
one preexisting type.

This is true of ANY language I have dealt with.

if(x) .....

The following is an excerpt from Wikipedia's article on C#:

C# supports a strict boolean type, bool. Statements that take
conditions, such as while and if, require an expression of a boolean
type. While C++ also has a boolean type, it can be freely converted to
and from integers, and expressions such as if(a) require only that a is
convertible to bool, allowing a to be an int, or a pointer. C#
disallows this 'integer meaning true or false' approach on the grounds
that forcing programmers to use expressions that return exactly bool
prevents certain types of programming mistakes.

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

I never said a boolean type was silly or useless. It's just not an
essential type however.

I would agree that is silly.

OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between
various competing considerations and C had, until C99, chosen not to
implement a boolean type. Now it has one, but not, apparently, to the
OP's satisfaction.

It is fairly clear to me that a boolean type would only make code
cleaner.

It might. OTOH the "type explosion" introduced by C99 can also be argued
as, to an extent, damaging one of C's strengths - it's simplicity.

Would I use them? Probably not :-; I'm too entrenched in zero
and non zero.

Personally I use boolean objects only occasionally. I use C99's
definition when it's available or define it myself. As Malcolm notes,
there is a small possibility of a non-Standard definition conflicting
with another definition in library code, but I haven't encountered that
problem yet.

 

[Keith Thompson]

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.

The trouble is that there are a gazillion subtly different
programmer-defined typedef. I might use
typedef enum { false, true } bool;
and you might use
typedef int bool;
#define false 0
#define true 1
and anyone trying to mix my code with yours has to resolve the
incompatible declarations. The name collision problem can be (mostly)
avoided with unique prefixes:
typedef enum { kst_false, kst_true } kst_bool;
typedef int jjf_bool;
#define jjf_false 0
#define jjf_true 1
but that's ugly.

The point of defining it once and for all in the language isn't that
defining it yourself is too hard; it's that it's easy enough that
everyone does it incompatibly.

C99 *could* have used a simple typedef and a couple of macros in
<stdbool.h>:
typedef int bool; /* or perhaps "typedef intfast8_t bool;" */
#define false 0
#define true 1
but to get the desired behavior of converting any scalar value to bool
and getting either 0 or 1 (false or true), it was necessary to create
a new fundamental type _Bool.

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.

I agree that the lack of a boolean type it's not a major flaw, but I'm
glad C99 added it.

If I were designing C from scratch today, I'd probably make bool a
built-in type from the beginning, make the relational and equality
operators yield bool results, and require bool expressions for
conditions. (I personally wouldn't provide implicit conversions to
bool; others would want that.)

 

[Richard]

However it is one possible reason why C's designers did not consider a
dedicated boolean type as important.



You cannot get rid of some types without destroying the core language.
Also note that typedef cannot be used without the presence of at least
one preexisting type.


The following is an excerpt from Wikipedia's article on C#:

C# supports a strict boolean type, bool. Statements that take
conditions, such as while and if, require an expression of a boolean
type. While C++ also has a boolean type, it can be freely converted to
and from integers, and expressions such as if(a) require only that a is
convertible to bool, allowing a to be an int, or a pointer. C#
disallows this 'integer meaning true or false' approach on the grounds
that forcing programmers to use expressions that return exactly bool
prevents certain types of programming mistakes.


I never said a boolean type was silly or useless. It's just not an
essential type however.


OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

various competing considerations and C had, until C99, chosen not to
implement a boolean type. Now it has one, but not, apparently, to the
OP's satisfaction.



It might. OTOH the "type explosion" introduced by C99 can also be argued
as, to an extent, damaging one of C's strengths - it's simplicity.

Again, you are taking the argument to ridiculous places in order to drag
it back with the voice of reason. We are not talking type explosion. We
are talking the most basic type in existance - a boolean value.

Personally I use boolean objects only occasionally. I use C99's
definition when it's available or define it myself. As Malcolm notes,
there is a small possibility of a non-Standard definition conflicting
with another definition in library code, but I haven't encountered that
problem yet.

Hmm. Possibly. But I never knew a place quite like this ng for working
obscure "gotchas" which will simply never happen. 0 is false, anything
else is true.

 

[santosh]

There is no multibit boolean type,

Most typedefs for a boolean type use a multi bit base type.

<snip>

 

[Richard]

Most typedefs for a boolean type use a multi bit base type.

<snip>

So, OT then :-;

 

[santosh]

So, OT then :-;

Only if their definition or use involve non-Standard constructs.

 

[Keith Thompson]

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

[...]

Can you clarify that statement?

I'll ignore bit fields in the following; note that bit fields can only
be members of structs or unions, so they're not useful if you want to
declare single object.

All C types are multi-bit. Every C object has a size that's a whole
number of bytes, where each byte must be at least 8 bits. If you
declare an object of a boolean type, whether it's C99's _Bool or
soemthing you've defined yourself, that object must occupy at least 8
bits. Note that C doesn't have zero-sized objects.

(This "waste" of space isn't a problem in practice; using only a
single bit would typically require much more code to access it than
the data space you'd save.)

I see no straw man argument in what santosh posted above.

If you think that a programmer "can use his own [boolean type] with no
bits wasted if he so chooses", please demonstrate how you'd declare
such a type.

 

[Richard]

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

[...]

Can you clarify that statement?

That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.

I'll ignore bit fields in the following; note that bit fields can only
be members of structs or unions, so they're not useful if you want to
declare single object.

All C types are multi-bit. Every C object has a size that's a whole

Yes. But there is no boolean type : multibit or not.

number of bytes, where each byte must be at least 8 bits. If you
declare an object of a boolean type, whether it's C99's _Bool or
soemthing you've defined yourself, that object must occupy at least 8
bits. Note that C doesn't have zero-sized objects.

(This "waste" of space isn't a problem in practice; using only a
single bit would typically require much more code to access it than
the data space you'd save.)

Exactly. Hence my comment on it being a silly issue.

I see no straw man argument in what santosh posted above.

If you think that a programmer "can use his own [boolean type] with no
bits wasted if he so chooses", please demonstrate how you'd declare
such a type.

I don't think that and never suggested otherwise.

 

[Mark McIntyre]

Documentation.

I tend to find the _name_ of an object is better documentation. The
type of an object is relatively invisible to a reader of the code.

For example
int booleantest;

conveys just as much as

bool test;

and possibly more.

I'm assuming you don't propose Hungarian notation...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard]

I tend to find the _name_ of an object is better documentation. The
type of an object is relatively invisible to a reader of the code.

For example
int booleantest;

conveys just as much as

bool test;

and possibly more.

I'm assuming you don't propose Hungarian notation...

Your naming was pretty much Hungarian notation.

Type is important and gives a lot of information when debugging since
the correct format for that type is used for displayed the variables of
interest.

 

[Old Wolf]

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?

Example 1:

if ( 0x35A & 0x100 )
foo();

Example 2:

bool result = 0x35A & 0x100;

if ( result )
foo();

Example 3:

bool bar() { return 0x35A & 0x100; }
/*...*/
if ( bar() )
foo();

If bool is a typedef for char then foo will not be called
in examples 2 and 3. If 'bool' were a true boolean type,
then foo will be called in all cases.

IMHO, using the word 'bool' for a non-boolean type is
obfuscated.

 

[Keith Thompson]

OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

[...]

Can you clarify that statement?

That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.
[snip]

All C types are multi-bit. Every C object has a size that's a whole

Yes. But there is no boolean type : multibit or not.

Your statement that "there is no multibit boolean type" could easily
be taken to imply that there is a boolean type that's not multibit.
In fact, that's exactly how I read it. If you had said "there is no
boolean type" from the beginning, you could have avoided a great deal
of confusion.

It just didn't occur to me that you would ignore the existence of
_Bool and bool in C99, which have been discussed in this very thread.

In C90, you can easily declare your own boolean type; numerous
examples have been posted here. Any such type is going to be multibit
(barring the use of compiler extensions that might allow for one-bit
types). Such a type is a "boolean type" by any reasonable definition
of that phrase.

In C99, a predefined boolean type already exists, and like all other
types (ignoring bit fields), it must be multibit.

 

[Richard]

[...]
OP's statement isn't silly. A multi bit boolean type _does_ waste some
space. As in many other things, it's a matter of trade-off between

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.
[...]

Can you clarify that statement?

That there exists no multibit boolean type. Nothing more nothing
less. Anything else is personal preference/implementation.
[snip]

All C types are multi-bit. Every C object has a size that's a whole

Yes. But there is no boolean type : multibit or not.

Your statement that "there is no multibit boolean type" could easily
be taken to imply that there is a boolean type that's not multibit.
In fact, that's exactly how I read it. If you had said "there is no
boolean type" from the beginning, you could have avoided a great deal
of confusion.

Since the entire thread is based on there being no boolean type I felt
that somewhat unnecessary.

 

[J. J. Farrell]

Example 1:

if ( 0x35A & 0x100 )
foo();

Example 2:

bool result = 0x35A & 0x100;

if ( result )
foo();

Example 3:

bool bar() { return 0x35A & 0x100; }
/*...*/
if ( bar() )
foo();

If bool is a typedef for char then foo will not be called
in examples 2 and 3. If 'bool' were a true boolean type,
then foo will be called in all cases.

IMHO, using the word 'bool' for a non-boolean type is
obfuscated.

Granted, but you are assuming a particular interpretation of what is
meant by "a boolean type"; in particular, you're assuming well-defined
conversion from other types. What you describe here is certainly
useful, but is not necessarily what everyone would think of as "a
boolean type". I was thinking in terms of an object which holds the
traditional C concept of a boolean - if it's value is zero it is
false, else it is true - without automatic conversion from other
types. Your concept is more powerful and useful, and does require a
fundamental type built in to the language.

 

[Tor Rustad]

Keith Thompson wrote:

[...]

I agree that the lack of a boolean type it's not a major flaw, but I'm
glad C99 added it.

If I were designing C from scratch today, I'd probably make bool a
built-in type from the beginning, make the relational and equality
operators yield bool results, and require bool expressions for
conditions. (I personally wouldn't provide implicit conversions to
bool; others would want that.)

_Bool is ugly, using <stdbool.h> is ugly, providing bool/true/false via
macros are ugly

The fear of breaking existing code in C99, was IMO not a sufficient
reason for bringing such ugly constructs forward. How hard would it have
been, to grep an existing project for bool/false/true?

 

[Jack Klein]

Keith Thompson wrote:

[...]

I agree that the lack of a boolean type it's not a major flaw, but I'm
glad C99 added it.

If I were designing C from scratch today, I'd probably make bool a
built-in type from the beginning, make the relational and equality
operators yield bool results, and require bool expressions for
conditions. (I personally wouldn't provide implicit conversions to
bool; others would want that.)

_Bool is ugly, using <stdbool.h> is ugly, providing bool/true/false via
macros are ugly

Nowhere in the mandate of the standard committee is there any
requirement to avoid keywords or other identifiers that Tor Rustad, or
Jack Klein, or any other C programmer or group of C programmers
considers ugly.

The fear of breaking existing code in C99, was IMO not a sufficient
reason for bringing such ugly constructs forward. How hard would it have
been, to grep an existing project for bool/false/true?

Not so hard perhaps. But how hard would it be in some industries to
document all of the code changes to hundreds or thousands of files?
And why force that work on people with large code bases with no gain
for their efforts?

The committee does have a mandate to avoid breaking existing code,
even if that code could be fixed with a "simple" (maybe), find and
replace.

_Bool and _Complex do not break any existing code that did not invade
the implementation's reserved namespace.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Richard Heathfield]

Keith Thompson said:

There is no multibit boolean type, you are erecting straw men and
knocking them down yourself. The programmer can use his own with no bits
wasted if he so chooses.

[...]

Can you clarify that statement?

Feeding trolls is of course your prerogative, Keith, but it seems to me to
be strange behaviour from one who encourages others to starve them.

 

[CBFalconer]

.... snip ...

Nowhere in the mandate of the standard committee is there any
requirement to avoid keywords or other identifiers that Tor
Rustad, or Jack Klein, or any other C programmer or group of
C programmers considers ugly.

However there is a strong urge to not create new reserved words in
the user namespace, which can in turn necessitate large amounts of
editing.

A useful solution for this sort of problem is ID2ID-20, which can
easily make the same changes over a list of files. It is written
in purely standard C, and available at:

<http://cbfalconer.home.att.net/download/>

 

[Richard]

However there is a strong urge to not create new reserved words in
the user namespace, which can in turn necessitate large amounts of
editing.

A useful solution for this sort of problem is ID2ID-20, which can
easily make the same changes over a list of files. It is written
in purely standard C, and available at:

<http://cbfalconer.home.att.net/download/>

Most decent C IDEs support renaming/refactoring within the IDE : no need
for 3rd party hacks.

e.g for Eclipse:

http://www.ibm.com/developerworks/library/os-ecref/