stdbool.h

J

Jorgen Grahn

I'm sitting with a C99 code base and thinking about introducing
<stdbool.h>, the 'bool' type and true/false. Anything special I
have to keep in mind?

Am I likely to end up in conflict with people who feel stdbool.h
is an abomination? More than other C99 features, that is.

My background is in C++ where I of course use bool a lot. In C I tend
to use naked ints for booleans, and 0 and 1 when I need a true or
false constant. Works well, but it's not exactly self-documenting.

/Jorgen
 
S

Stefan Ram

Jorgen Grahn said:
I'm sitting with a C99 code base and thinking about introducing
<stdbool.h>, the 'bool' type and true/false. Anything special I
have to keep in mind?

Yes. Do not write code like

if( isprint( ch )== true )...
 
O

Osmium

Jorgen Grahn said:
I'm sitting with a C99 code base and thinking about introducing
<stdbool.h>, the 'bool' type and true/false. Anything special I
have to keep in mind?

Am I likely to end up in conflict with people who feel stdbool.h
is an abomination? More than other C99 features, that is.

My background is in C++ where I of course use bool a lot. In C I tend
to use naked ints for booleans, and 0 and 1 when I need a true or
false constant. Works well, but it's not exactly self-documenting.

IMO adding that stuff after all these years is like putting lipstick on a
pig.
 
J

jacob navia

Le 01/03/2014 22:37, Osmium a écrit :
IMO adding that stuff after all these years is like putting lipstick on a
pig.

One of the characteristics of many C++ programmers is their attitude
towards people prgramming in other languages.

Java programmers are regularly insulted in their discussion group,
together with C# programmers or any other programmers that do not buy
the C++ stuff and dare program in another language.

Of course this doesn't apply to all C++ programmers. Only to those that
insult other people or programmint tools of course.

It is a tradition of them, to come to this forum to "preach the good
word", and start writing things like the sentence above.

Well, it is a state of mind, and you eventually get used to their stuff,
their arrogance, their absolute ignorance. It is impossible to avoid: if
you take a lot of people you *must* have a moron among them. It is
inevitable.
 
J

jacob navia

Le 01/03/2014 22:10, Jorgen Grahn a écrit :
I'm sitting with a C99 code base and thinking about introducing
<stdbool.h>, the 'bool' type and true/false. Anything special I
have to keep in mind?

Yes. The first thing is:

Do not do that.


Get a C99 compiler and it will come with a stdbool.h.

If you write your own, name it diffeerently than stdbool.h since that is
the name of the standard file that should come with the distribution of
the compiler you use.
Am I likely to end up in conflict with people who feel stdbool.h
is an abomination? More than other C99 features, that is.

The people that think that using "bool" is "an abomination" are not very
bright, and you can safely ignore their opinion.
My background is in C++ where I of course use bool a lot.
Normal.

In C I tend
to use naked ints for booleans, and 0 and 1 when I need a true or
false constant. Works well, but it's not exactly self-documenting.

That is why the language provides <stdbool.h> since 15 years...
 
J

Jorgen Grahn

Le 01/03/2014 22:10, Jorgen Grahn a écrit :

Yes. The first thing is:

Do not do that.


Get a C99 compiler and it will come with a stdbool.h.

If you write your own, name it diffeerently than stdbool.h since that is
the name of the standard file that should come with the distribution of
the compiler you use.

You misunderstand -- my intention is not to /write/ stdbool.h, just
start /using/ it. The code is already C99.

/Jorgen
 
J

Jorgen Grahn

Le 01/03/2014 22:37, Osmium a écrit :

One of the characteristics of many C++ programmers is their attitude
towards people prgramming in other languages.

Osmium might just as well oppose anything newer than ANSI C, or this
particular part of C99. It's the latter which interests me -- whether
the few who use C99 also use stdbool.h. I have never seen it used,
but I've seen people complain about the builtin name _Bool.

/Jorgen
 
O

Osmium

Osmium might just as well oppose anything newer than ANSI C, or this
particular part of C99. It's the latter which interests me -- whether
the few who use C99 also use stdbool.h. I have never seen it used,
but I've seen people complain about the builtin name _Bool.

It's a cosmetic change, it adds no functionality. It violates one of the
basic philosophies of the language, lean and mean. The barrier to changing a
language should be higher than the barrier to controversial original
content. It's just plain frivolous.
 
J

jacob navia

Le 02/03/2014 01:48, Osmium a écrit :
It's a cosmetic change, it adds no functionality.

printf("%d\n",(bool)6);

prints

1

A _Bool value can have only two values. This is a new functionality that
was added to the language by the C99 standard, and eliminates the
problems when a boolean was represented by an integer and could have ANY
value an integer can hold.
It violates one of the
basic philosophies of the language, lean and mean.

So, C is no longer "mean and lean" because it supports bool?

What a nonsense really.
The barrier to changing a
language should be higher than the barrier to controversial original
content. It's just plain frivolous.

Boolean values arise everywhere you program something. It is a natural
consequence of the boolean logic used in the circuits that build the
computers we use. To say that "bool" is "frivolus" is completely
nonsense, there isn't any real program that doesn't use "bool".
 
S

Stefan Ram

jacob navia said:
printf("%d\n",(bool)6);
prints
1

!!6 is the idiom.
A _Bool value can have only two values. This is a new functionality that
was added to the language by the C99 standard, and eliminates the
problems when a boolean was represented by an integer and could have ANY
value an integer can hold.

This is a way to implement isupper:

#define isupper(c) (( __ctype__ + 8 )[ c ]& _H )

. One could surely reduce the result to the set {0,1},
but this might take an additional processor cycle, and
the caller might not need it. If the caller should
need it, he is free to

#define ISUPPER(c) (!!(isupper(c)))

, but why pay for what one does not need?
Boolean values arise everywhere you program something.

On other languages. In C we have int. if, while, all work
with int.

»God made the integers, all the rest is the work of man.«

Leopold Kronecker
It is a natural consequence of the boolean logic used in the
circuits that build the computers we use.

It is a natural consequence of machine instructions like
CBZ (Conditional Branch on Zero) and
CBNZ (Conditional Branch on Non-Zero)
that also care about ints, not bools.
 
M

Malcolm McLean

I'm sitting with a C99 code base and thinking about introducing
<stdbool.h>, the 'bool' type and true/false. Anything special
have to keep in mind?
bool breaks libraries.

The snag is that you have, say some image-processing routines. One of them
test whether a point is in a polygon.
OK so that's
bool ptinpoly(POLYGON *poly, double x, double y)

That would be OK if bool was a built-in type. But a geometry library as no
business exporting a boolean type to the rest of the program. If you define
bool in any way, either you conflict with someone else, or you have bool,
boolean, BOOL, bit, flag, logical, and bool_t all swilling around your code
for the same thing.

Qt suggest that people don't use boolean for parameters. Their thinking is
that

sd = standard_deviation(x, N, true);

is confusing. The function obviously calculates the standard deviation, x is
obviously the samples and N size. But does true mean population or sample
deviation? Or is is something else entirely? Very hard to be sure.

sd = standard_deviation(x, N, SD_POPULATION);

is the way to go.
 
I

Ian Collins

Malcolm said:
bool breaks libraries.

The snag is that you have, say some image-processing routines. One of them
test whether a point is in a polygon.
OK so that's
bool ptinpoly(POLYGON *poly, double x, double y)

That would be OK if bool was a built-in type.

Well it is if you use the the standard type, which was introduced to
solve the problems you describe.
Qt suggest that people don't use boolean for parameters. Their thinking is
that

sd = standard_deviation(x, N, true);

is confusing. The function obviously calculates the standard deviation, x is
obviously the samples and N size. But does true mean population or sample
deviation? Or is is something else entirely? Very hard to be sure.

sd = standard_deviation(x, N, SD_POPULATION);

is the way to go.

or better still, use bool and declare

const bool sd_population = true;

and use that.
 
T

Thomas Richter

Qt suggest that people don't use boolean for parameters. Their thinking is
that

sd = standard_deviation(x, N, true);

is confusing. The function obviously calculates the standard deviation, x is
obviously the samples and N size. But does true mean population or sample
deviation? Or is is something else entirely? Very hard to be sure.

I don't get this argument. It is an argument against improper interface
documentation, but not against bool. Whether the argument is int or not
does not make any difference here.

Greetings,
Thomas
 
B

BartC

Boolean values arise everywhere you program something. It is a natural
consequence of the boolean logic used in the circuits that build the
computers we use. To say that "bool" is "frivolus" is completely nonsense,
there isn't any real program that doesn't use "bool".

Maybe a proper 'Bit' type would be more appropriate then.

Something more general than the 'bitfield' types in a struct, and more
lightweight than bitstrings of your containers library. And so that in:

Bit a[64];

sizeof(a) would be 8 (when CHAR_BIT is 8). However they would need their own
special kind of pointer, and a special sizeof_bits().

By contrast, with:

_Bool b[64];

sizeof(b) generally gives 64.

But a single Bit variable would have to be be the same size as a single
_Bool (one char).
 
S

Sebastian Doht

Am 02.03.2014 00:58, schrieb Jorgen Grahn:
Osmium might just as well oppose anything newer than ANSI C, or this
particular part of C99. It's the latter which interests me -- whether
the few who use C99 also use stdbool.h. I have never seen it used,
but I've seen people complain about the builtin name _Bool.

/Jorgen

You should rather ask the people you are working with than a NG. I used
to work on a embedded platform with a C compiler with partial C99
support. Using bool there was quite common. But must people working on
the platform had knowledge in at least another programming language so
bool was nothing special for them. We had the innofficial rule that C99
features which are supported when switching to C++ are allowed (bool and
const where ok; VLAs were forbidden).

Greetz,

Sebastian
 
J

Jorgen Grahn

On other languages. In C we have int. if, while, all work
with int.

We used to, but for the past fifteen years we have also had bool.

Seems to me C is now in the same place as C++: booleanness is still
based on int, but when you need to store a boolean value you have the
option to give it the type bool.

(After having written that, I'm suddenly unsure whether 1==2 has the
type int or bool in C++ ... the difference is minor.)

/Jorgen
 
B

Ben Bacarisse

Malcolm McLean said:
Qt suggest that people don't use boolean for parameters. Their thinking is
that

sd = standard_deviation(x, N, true);

is confusing. The function obviously calculates the standard deviation, x is
obviously the samples and N size. But does true mean population or sample
deviation? Or is is something else entirely? Very hard to be sure.

This is an argument against using Boolean constants as arguments, not
about using the bool type for parameters. The parameter can have as
descriptive a name as you like.

But it has nothing at all to do with Boolean types at all. The same
advice should apply to all unexplained constants in code. There is
nothing especially mysterious about true and false any more that than
there is about 0 or 42 or 5.6.
sd = standard_deviation(x, N, SD_POPULATION);

is the way to go.

That's one way to go, but there are others depending on the situation.
 
M

Malcolm McLean

This is an argument against using Boolean constants as arguments, no
about using the bool type for parameters. The parameter can have as
descriptive a name as you like.

But it has nothing at all to do with Boolean types at all. The same
advice should apply to all unexplained constants in code. There is
nothing especially mysterious about true and false any more that than
there is about 0 or 42 or 5.6.
People aren't machines.

They'll pass "true" or "false" to a function because it's already a descriptive
identifier. They'll use bool as a parameter and not provide any defined #constants because it's obvious that EnableControl(true) means enable it
and EnableControl(false) means disable it. After all, the other way round
would be silly. They can't make the leap to the poor person totally unfamiliar
with the API who sees EnableControl(false) embedded in a long and confusing
function which is somehow setting the control to the wrong state.

OTOH if you have #define CONTROL_ENABLE 42 few people will pass a raw 42.
 
J

Jorgen Grahn

Am 02.03.2014 00:58, schrieb Jorgen Grahn:

You should rather ask the people you are working with than a NG.

I'll do that too. Except if stdbool.h (which I've never used) turned
out to be universally loathed I might not bother.

I was aware that it would be tricky to tell, since on comp.lang.c you
can find people who feel strongly against /anything/.
I used
to work on a embedded platform with a C compiler with partial C99
support. Using bool there was quite common. But must people working on
the platform had knowledge in at least another programming language so
bool was nothing special for them. We had the innofficial rule that C99
features which are supported when switching to C++ are allowed (bool and
const where ok; VLAs were forbidden).

Fortunately for me 'const' is already accepted here. Otherwise we're
conservative on average. C++ is foreign and threatening, and the C99
features that /are/ used already leaked in via third-party libraries.

These libraries don't use stdbool for some reason. Designated
initializers and inline yes; stdbool and declarations not at the top
of a block no. Perhaps they use the Linux kernel subset of C99.

/Jorgen
 
E

Eric Sosman

It's a cosmetic change, it adds no functionality. It violates one of the
basic philosophies of the language, lean and mean. The barrier to changing a
language should be higher than the barrier to controversial original
content. It's just plain frivolous.

"No functionality" overstates (understates?) the reality;
the _Bool type does in fact provide function not available via
other types:

int i = 0.1;
if (i) puts("i is true");
_Bool b = 0.1;
if (b) puts("b is true");

If you'd said "no *important* functionality," though, I'd have agreed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top