468,526 Members | 2,097 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,526 developers. It's quick & easy.

Best Place to Define TRUE/FALSE

Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about these?
------------------------------------------------------------
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jan 14 '07 #1
71 32139
David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about these?
No, it's each to his/her own, unless you use C99.
------------------------------------------------------------
Please trim this to two dashes, newsreaders look for a line "--<cr>" as
a signature separator.

--
Ian Collins.
Jan 14 '07 #2

"David T. Ashley" <dt*@e3ft.comwrote in message
news:J8******************************@giganews.com ...
Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about these?
It's in stdbool.h . We just looked at it.
news:12*************@corp.supernews.com...
LS
Jan 14 '07 #3

David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?
In your own headers.
Are they in any of the standard include files, ever?
AFAICT, no. The C standard doesn't define them
Do any standards apply?
Only to the extent that they delimit what must be in the standard
headers.
What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif
O....K.....

If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif
?

Jan 14 '07 #4
"Ian Collins" <ia******@hotmail.comwrote in message
news:50**************@mid.individual.net...
David T. Ashley wrote:
>Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about
these?

No, it's each to his/her own, unless you use C99.
>------------------------------------------------------------
Please trim this to two dashes, newsreaders look for a line "--<cr>" as
a signature separator.

--
Ian Collins.
OK, done. Just out of curiousity, which newsreader and platform are you
using?

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jan 14 '07 #5
2007-01-14 <J8******************************@giganews.com>,
David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?
stdbool.h defines true and false in c99.
Jan 14 '07 #6
"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>
If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif
I'm not sure that this is advantageous over FALSE=0, TRUE=1. Any
advantages?

Also, I think the tests used are more significant.

This:

<begin>
if (x==FALSE)
...
else if (x==TRUE)
...
<end>

would seem to lead to trouble. In fact, maybe defining TRUE is a bad idea
.... every test should be either ==FALSE or != FALSE.
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jan 14 '07 #7

"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>
David T. Ashley wrote:
>Where is the best place to define TRUE and FALSE?

In your own headers.
>Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them
[snip]
I think that this is an example of a statement that was true in '89 but
false in '99 . I've heard rumors about long, impassioned battles about '89
vs '99, but I've never read them. I believe that the leading proponent of
the merits of the 89 standard is Richard Heathfield, but I have not read
what he has to say categorically.

It would seem that forcing the existence of stdbool.h and with it
interoperability with common C extensions would be a good thing. LS
Jan 14 '07 #8
David T. Ashley wrote:
>>--
Ian Collins.
You should also set you reader to trim other people's signatures.
>
OK, done. Just out of curiousity, which newsreader and platform are you
using?
Mozilla/Solaris.

--
Ian Collins.
Jan 14 '07 #9
"David T. Ashley" wrote:
>
Where is the best place to define TRUE and FALSE?
Are they in any of the standard include files, ever?
Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking
about these?
Yes, in C99. I use the following to adapt to the compiler
available. The result is that all the C99 conventions are
followed. Note lower case true/false, per C99.

/* Standard defines of operators, usable on C90 up */
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Jan 14 '07 #10
Ian Collins <ia******@hotmail.comwrites:
David T. Ashley wrote:
[...]
>------------------------------------------------------------
Please trim this to two dashes, newsreaders look for a line "--<cr>" as
a signature separator.
The standard signature separator is a line consisting of two dashes
and a space: "-- ". (Both of you have this right.)

--
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.
Jan 14 '07 #11
"Lew Pitcher" <lp******@sympatico.cawrites:
[...]
If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif
?
Why bother?

#define FALSE 0
#define TRUE 1

The parentheses are not necessary, and the value of !0 will never be
anything other than 1 in any language called "C".

Section 9 of the comp.lang.c FAQ, <http://www.c-faq.com/>, covers this
quite well.

--
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.
Jan 14 '07 #12
"David T. Ashley" <dt*@e3ft.comwrites:
"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif

I'm not sure that this is advantageous over FALSE=0, TRUE=1. Any
advantages?
None at all.
Also, I think the tests used are more significant.

This:

<begin>
if (x==FALSE)
...
else if (x==TRUE)
...
<end>

would seem to lead to trouble. In fact, maybe defining TRUE is a bad idea
... every test should be either ==FALSE or != FALSE.
If you've defined FALSE and TRUE, don't compare anything for equality
to either of them.

Rather than "if (x == TRUE)", just write "if (x)".
Rather than "if (x == FALSE"), just write "if (!x)".

If you think that "if (x == TRUE)" is better than "if (x)", you should
think that "if ((x == TRUE) == TRUE)" is even better.

And "x" should have a name that makes it clear that it's a condition,
for example "done" or "more_data".

--
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.
Jan 14 '07 #13
"Lane Straatman" <in*****@invalid.netwrites:
"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>>
David T. Ashley wrote:
>>Where is the best place to define TRUE and FALSE?

In your own headers.
>>Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them
[snip]
I think that this is an example of a statement that was true in '89 but
false in '99 . I've heard rumors about long, impassioned battles about '89
vs '99, but I've never read them. I believe that the leading proponent of
the merits of the 89 standard is Richard Heathfield, but I have not read
what he has to say categorically.

It would seem that forcing the existence of stdbool.h and with it
interoperability with common C extensions would be a good thing. LS
A quick summary:

Opinions vary about whether the C99 standard is a significant
improvement over the C90 standard. But regardless of that, it's a
fact that there are still very few conforming C99 implementations, so
if you want to write maximally portable code you need to stick to C90.

--
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.
Jan 14 '07 #14
Keith Thompson wrote:
"Lane Straatman" <in*****@invalid.netwrites:
"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>
David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?

In your own headers.

Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them
[snip]
I think that this is an example of a statement that was true in '89 but
false in '99 . I've heard rumors about long, impassioned battles about '89
vs '99, but I've never read them. I believe that the leading proponent of
the merits of the 89 standard is Richard Heathfield, but I have not read
what he has to say categorically.

It would seem that forcing the existence of stdbool.h and with it
interoperability with common C extensions would be a good thing. LS

A quick summary:

Opinions vary about whether the C99 standard is a significant
improvement over the C90 standard. But regardless of that, it's a
fact that there are still very few conforming C99 implementations, so
if you want to write maximally portable code you need to stick to C90.
You mean the C99-compatible subset of C90, right?

Jan 14 '07 #15
David T. Ashley wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:50**************@mid.individual.net...
David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

Do any standards apply?

What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about
these?
No, it's each to his/her own, unless you use C99.
------------------------------------------------------------
Please trim this to two dashes, newsreaders look for a line "--<cr>" as
a signature separator.

--
Ian Collins.

OK, done. Just out of curiousity, which newsreader and platform are you
using?
Ian has already answered this but just so you know, you can usually
obtain this information by examining the message headers, in this case
it yields:

User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7.13)
Gecko/20060510

Robert Gamble

Jan 14 '07 #16

"CBFalconer" <cb********@yahoo.comwrote in message
news:45***************@yahoo.com...
"David T. Ashley" wrote:
>>
Where is the best place to define TRUE and FALSE?
But is there a "standard place" or a standard way of thinking
about these?

Yes, in C99. I use the following to adapt to the compiler
available. The result is that all the C99 conventions are
followed. Note lower case true/false, per C99.

/* Standard defines of operators, usable on C90 up */
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif
This is the only header you need for the whole standard regarding operators?
LS
--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
--
Hoare's sort was an improvement on Shell's
Jan 14 '07 #17
"Harald van Dijk" <tr*****@gmail.comwrites:
Keith Thompson wrote:
[...]
>A quick summary:

Opinions vary about whether the C99 standard is a significant
improvement over the C90 standard. But regardless of that, it's a
fact that there are still very few conforming C99 implementations, so
if you want to write maximally portable code you need to stick to C90.

You mean the C99-compatible subset of C90, right?
Yes, you're right. (Mostly that means avoiding the new keywords.)

--
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.
Jan 14 '07 #18

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Harald van D?k" <tr*****@gmail.comwrites:
>Keith Thompson wrote:
[...]
>>A quick summary:

Opinions vary about whether the C99 standard is a significant
improvement over the C90 standard. But regardless of that, it's a
fact that there are still very few conforming C99 implementations, so
if you want to write maximally portable code you need to stick to C90.

You mean the C99-compatible subset of C90, right?

Yes, you're right. (Mostly that means avoiding the new keywords.)
Does 'bool' count as a keyword? LS
Jan 14 '07 #19
Lane Straatman said:
"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...
>>
David T. Ashley wrote:
>>Where is the best place to define TRUE and FALSE?

In your own headers.
>>Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them
Correct.
[snip]
I think that this is an example of a statement that was true in '89 but
false in '99 .
Not so. Neither C90 nor C99 defines TRUE. I didn't actually check for FALSE,
but I'm 99.9% certain it doesn't appear within the text of the Standard.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 14 '07 #20
"Lane Straatman" <in*****@invalid.netwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>"Harald van D?k" <tr*****@gmail.comwrites:
>>Keith Thompson wrote:
[...]
>>>A quick summary:

Opinions vary about whether the C99 standard is a significant
improvement over the C90 standard. But regardless of that, it's a
fact that there are still very few conforming C99 implementations, so
if you want to write maximally portable code you need to stick to C90.

You mean the C99-compatible subset of C90, right?

Yes, you're right. (Mostly that means avoiding the new keywords.)
Does 'bool' count as a keyword? LS
No, "bool" is a macro that expands to the keyword "_Bool". You're
free to use it as long as you don't have a "#include <stdbool.h>".

--
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.
Jan 14 '07 #21

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Lew Pitcher" <lp******@sympatico.cawrites:
[...]
>If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif
?

Why bother?

#define FALSE 0
#define TRUE 1

The parentheses are not necessary, and the value of !0 will never be
anything other than 1 in any language called "C".
Where I work the coding guideline says we *always* have to put parentheses
around macros like that. Maybe a bit overdone but I can see where its coming
from.

Jan 14 '07 #22
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"David T. Ashley" <dt*@e3ft.comwrites:
>"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegro ups.com...
>>If you are going that route, then might I suggest
#ifndef FALSE
#define FALSE (0)
#define TRUE (!(FALSE))
#endif

I'm not sure that this is advantageous over FALSE=0, TRUE=1. Any
advantages?

None at all.
>Also, I think the tests used are more significant.

This:

<begin>
if (x==FALSE)
...
else if (x==TRUE)
...
<end>

would seem to lead to trouble. In fact, maybe defining TRUE is a bad
idea
... every test should be either ==FALSE or != FALSE.

If you've defined FALSE and TRUE, don't compare anything for equality
to either of them.

Rather than "if (x == TRUE)", just write "if (x)".
Rather than "if (x == FALSE"), just write "if (!x)".

If you think that "if (x == TRUE)" is better than "if (x)", you should
think that "if ((x == TRUE) == TRUE)" is even better.

And "x" should have a name that makes it clear that it's a condition,
for example "done" or "more_data".
The issue in my mind is "equivalence classing": whatever conventions are
true should be mutually exclusive and mutually exhaustive with respect to
the data type involved.

(x) and (!x) as you suggested meet that requirement.

(==0) and (!=0) as nobody has yet suggested meet that requirement.

(==FALSE) and (!=FALSE) as I suggested meet that requirement.

(==FALSE) and (==TRUE) do not.

I think that in practice "TRUE" should only be used for assigning and never
for testing.

The method of testing that you suggested is probably the best.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jan 14 '07 #23
"David T. Ashley" <dt*@e3ft.comwrites:
[...]
The issue in my mind is "equivalence classing": whatever conventions are
true should be mutually exclusive and mutually exhaustive with respect to
the data type involved.

(x) and (!x) as you suggested meet that requirement.

(==0) and (!=0) as nobody has yet suggested meet that requirement.

(==FALSE) and (!=FALSE) as I suggested meet that requirement.

(==FALSE) and (==TRUE) do not.

I think that in practice "TRUE" should only be used for assigning and never
for testing.
Neither TRUE nor FALSE should be used for testing; both should be used
only for assigning. One of them can safely be used in equality
comparisons, but it's easier to be consistent than to remember which.
The method of testing that you suggested is probably the best.
I agree (obviously).

The problem, of course, is that there's only one false value (0), but
there are arbitrarily many true values (all values other than 0). The
value chosen for the macro/constant/whatever TRUE is in some sense
arbitrary.

--
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.
Jan 14 '07 #24
Richard Heathfield wrote:
Lane Straatman said:
>"Lew Pitcher" <lp******@sympatico.cawrote in message
>>David T. Ashley wrote:

Where is the best place to define TRUE and FALSE?

In your own headers.

Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them

Correct.
>[snip]
I think that this is an example of a statement that was true in
'89 but false in '99 .

Not so. Neither C90 nor C99 defines TRUE. I didn't actually check
for FALSE, but I'm 99.9% certain it doesn't appear within the text
of the Standard.
The operative verbiage, from N869, is:

7.16 Boolean type and values <stdbool.h>

[#1] The header <stdbool.hdefines four macros.

[#2] The macro

bool

expands to _Bool.

[#3] The remaining three macros are suitable for use in #if
preprocessing directives. They are

true

which expands to the integer constant 1, |

false

which expands to the integer constant 0, and |

__bool_true_false_are_defined

which expands to the decimal constant 1.

[#4] Notwithstanding the provisions of 7.1.3, a program is
permitted to undefine and perhaps then redefine the macros
bool, true, and false.200)

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Jan 14 '07 #25
CBFalconer said:
Richard Heathfield wrote:
<snip>
>Neither C90 nor C99 defines TRUE. I didn't actually check
for FALSE, but I'm 99.9% certain it doesn't appear within the text
of the Standard.

The operative verbiage, from N869, is:
....irrelevant, since it mentions neither TRUE nor FALSE.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 14 '07 #26
"David T. Ashley" <dt*@e3ft.comwrote in message
>
Where is the best place to define TRUE and FALSE?
Nowhere.
Is your symbol really necessary?
bool breaks libraries.

You can argue that C ought to have a standard human readable symbol for TRUE
and FALSE. However it is not your job to provide one.

Defining a symbol so fundamental forces everyone who calls your code to
write code in exactly the same style, or have a kludge which rapidly becomes
unreadable. It also makes your code harder for people used to the normal
convention to read. So you don't do it unless you know that you are only
person contributing code to the project.

Consider this

/*
Bloggs.h
#ifndef TRUE
#define TRUE 1
#endif
*/

/*
Muggins.h
#ifndef true
#define true 1
#endif
*/

/*
Dimbo.h
#define TRUE -1
*/

You'll always get a Dimbo.

Even if you don't have a Dimbo somewhere on your team

#define mymacro(x) (x == true) ? 1 : 100

a bit down

y = mymacro(TRUE);

is pretty confusing

Jan 14 '07 #27
"Malcolm McLean" <re*******@btinternet.comwrites:
You can argue that C ought to have a standard human readable symbol for TRUE
and FALSE. However it is not your job to provide one.
C *does* have a standard, human-readable symbol for TRUE and
FALSE. They are spelled true and false and they are declared in
<stdbool.h>.
--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield
Jan 14 '07 #28
Richard Heathfield wrote:
CBFalconer said:
Richard Heathfield wrote:

<snip>
>>Neither C90 nor C99 defines TRUE. I didn't actually check
for FALSE, but I'm 99.9% certain it doesn't appear within the
text of the Standard.

The operative verbiage, from N869, is:

...irrelevant, since it mentions neither TRUE nor FALSE.
The point is that C99 has standardized those names in lower case,
so I advise jumping on the bandwagon and conforming to that. A
slight babel reduction.

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Jan 14 '07 #29
On Sun, 14 Jan 2007 17:10:17 -0000, "Malcolm McLean"
<re*******@btinternet.comwrote:
>"David T. Ashley" <dt*@e3ft.comwrote in message
>>
Where is the best place to define TRUE and FALSE?
Nowhere.
Is your symbol really necessary?
bool breaks libraries.

You can argue that C ought to have a standard human readable symbol for TRUE
and FALSE. However it is not your job to provide one.

Defining a symbol so fundamental forces everyone who calls your code to
write code in exactly the same style, or have a kludge which rapidly becomes
unreadable. It also makes your code harder for people used to the normal
convention to read. So you don't do it unless you know that you are only
person contributing code to the project.

Consider this

/*
Bloggs.h
#ifndef TRUE
#define TRUE 1
#endif
*/

/*
Muggins.h
#ifndef true
#define true 1
#endif
*/
Preprocessor macros should use all uppercase. I think that's a de
facto convention.
>/*
Dimbo.h
#define TRUE -1
*/

You'll always get a Dimbo.

Even if you don't have a Dimbo somewhere on your team

#define mymacro(x) (x == true) ? 1 : 100
If x is a Boolean, then it shouldn't be compared to anything. This
should be:

#define mymacro(x) (x) ? 1 : 100
>a bit down

y = mymacro(TRUE);

is pretty confusing
Not if TRUE is defined like it should be:

#ifdef TRUE
#if !(TRUE == 1)
#error "TRUE may have been defined by a Dimbo--it's not equal to 1"
#endif
#else
#define TRUE 1
#endif

For completeness, here's how FALSE should be defined:

#ifdef FALSE
#if !(FALSE == 0)
#error "FALSE may have been defined by a Dimbo--it's not equal to 0"
#endif
#else
#define FALSE 0
#endif

I don't think code should depend on TRUE being 1. Code like this (in
which that variable x is a "Boolean"):

if ( x == TRUE )

should be written like this:

if ( x )

Best regards
--
jay
Jan 15 '07 #30
Richard Heathfield a écrit :
Lane Straatman said:
>>"Lew Pitcher" <lp******@sympatico.cawrote in message
news:11*********************@51g2000cwl.googlegr oups.com...
>>>David T. Ashley wrote:

Where is the best place to define TRUE and FALSE?

In your own headers.
Are they in any of the standard include files, ever?

AFAICT, no. The C standard doesn't define them


Correct.

>>[snip]
I think that this is an example of a statement that was true in '89 but
false in '99 .


Not so. Neither C90 nor C99 defines TRUE. I didn't actually check for FALSE,
but I'm 99.9% certain it doesn't appear within the text of the Standard.
This is wrong advice
Jan 15 '07 #31
jacob navia said:
Richard Heathfield a écrit :
<snip>
>Neither C90 nor C99 defines TRUE. I didn't actually check for
FALSE, but I'm 99.9% certain it doesn't appear within the text of the
Standard.

This is wrong advice
Chapter and verse, please, Mr Navia. (Translation: you're wrong.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 15 '07 #32
Richard Heathfield a écrit :
jacob navia said:

>>Richard Heathfield a écrit :


<snip>
>>>Neither C90 nor C99 defines TRUE. I didn't actually check for
FALSE, but I'm 99.9% certain it doesn't appear within the text of the
Standard.

This is wrong advice


Chapter and verse, please, Mr Navia. (Translation: you're wrong.)
This is wrong advice since you omit to mention that the C standard
defines true and false, and the same definition in upper case is
wrong and confusing for anyone reading the code.

No further polemic please. I will not reply
Jan 15 '07 #33
jacob navia said:
Richard Heathfield a écrit :
>jacob navia said:

>>>Richard Heathfield a écrit :


<snip>
>>>>Neither C90 nor C99 defines TRUE. I didn't actually check for
FALSE, but I'm 99.9% certain it doesn't appear within the text of the
Standard.
This is wrong advice


Chapter and verse, please, Mr Navia. (Translation: you're wrong.)

This is wrong advice
Nope.
since you omit to mention that the C standard
defines true and false,
I also omitted to mention that the C standard defines CHAR_MAX, strlen, and
the <<= operator. So what?
and the same definition in upper case is
wrong and confusing for anyone reading the code.
C is case sensitive, so TRUE is not the same definition in upper case as
true. They are different identifiers. To suggest otherwise is wrong and
confusing.
No further polemic please. I will not reply
Thank heaven for small mercies.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 15 '07 #34
David T. Ashley wrote:
Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?
As far as I know, no. However C99 does define 'true' and 'false' in
stdbool.h. They resolve into integer constant values 1 and 0
respectively.
Do any standards apply?
None except your own and that of any code to which you're interfacing.
What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about these?
Personally when I want to evaluate an object in a boolean manner I use
the construct:

if(!obj)
/* ... */
else
/* ... */

In my experience testing for truth or falsity against exact values is
rarely necessary in C. When such a situation arises, it most often due
to interfacing with third-party code.

If you do want to use them, then using C99's standard forms would
probably be better than rolling your own.

Jan 15 '07 #35

"santosh" <sa*********@gmail.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
David T. Ashley wrote:
>Where is the best place to define TRUE and FALSE?

Are they in any of the standard include files, ever?

As far as I know, no. However C99 does define 'true' and 'false' in
stdbool.h. They resolve into integer constant values 1 and 0
respectively.
>Do any standards apply?

None except your own and that of any code to which you're interfacing.
>What I've traditionally done is something like:

#ifndef (TRUE)
#define TRUE (1)
#endif

(and same for FALSE).

But is there a "standard place" or a standard way of thinking about
these?

Personally when I want to evaluate an object in a boolean manner I use
the construct:

if(!obj)
/* ... */
else
/* ... */

In my experience testing for truth or falsity against exact values is
rarely necessary in C. When such a situation arises, it most often due
to interfacing with third-party code.
own.
Since it's been part of a standard that we've all been a little late in
warming up to, the code would suffer the same sheer tonnage of wrongness as
we saw in this thread. I think having _Bool flags is a way to make *darn
sure* of something else more complicated. LS
Jan 16 '07 #36

"Lane Straatman" <in*****@invalid.netwrote in message
"santosh" <sa*********@gmail.comwrote in message
>In my experience testing for truth or falsity against exact values is
rarely necessary in C. When such a situation arises, it most often due
to interfacing with third-party code.
own.
Since it's been part of a standard that we've all been a little late in
warming up to, the code would suffer the same sheer tonnage of wrongness
as we saw in this thread. I think having _Bool flags is a way to make
*darn sure* of something else more complicated. LS
A failed standard creates its own problems.
#include <stdbool.h>
might provoke Oh no, damned thing in C99. We don't support that here.

#define TRUE 1
has the "bool breaks libraries" problem I mentioned elsethread.

So just using implicit false = 0, true = non-zero is best.
Jan 16 '07 #37
"Malcolm McLean" <re*******@btinternet.comwrites:
"Lane Straatman" <in*****@invalid.netwrote in message
>"santosh" <sa*********@gmail.comwrote in message
>>In my experience testing for truth or falsity against exact values is
rarely necessary in C. When such a situation arises, it most often due
to interfacing with third-party code.
own.
Since it's been part of a standard that we've all been a little late in
warming up to, the code would suffer the same sheer tonnage of wrongness
as we saw in this thread. I think having _Bool flags is a way to make
*darn sure* of something else more complicated. LS
A failed standard creates its own problems.
#include <stdbool.h>
might provoke Oh no, damned thing in C99. We don't support that here.

#define TRUE 1
has the "bool breaks libraries" problem I mentioned elsethread.

So just using implicit false = 0, true = non-zero is best.
But it's easy enough to use <stdbool.hconditionally.

For example:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.

CBFalconer has posted something similar that supports some additional
C99 features.

--
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.
Jan 16 '07 #38
Keith Thompson wrote:
"Malcolm McLean" <re*******@btinternet.comwrites:
>"Lane Straatman" <in*****@invalid.netwrote in message
>>"santosh" <sa*********@gmail.comwrote in message
In my experience testing for truth or falsity against exact values is
rarely necessary in C. When such a situation arises, it most often due
to interfacing with third-party code.
own.
Since it's been part of a standard that we've all been a little late in
warming up to, the code would suffer the same sheer tonnage of wrongness
as we saw in this thread. I think having _Bool flags is a way to make
*darn sure* of something else more complicated. LS
A failed standard creates its own problems.
#include <stdbool.h>
might provoke Oh no, damned thing in C99. We don't support that here.

#define TRUE 1
has the "bool breaks libraries" problem I mentioned elsethread.

So just using implicit false = 0, true = non-zero is best.

But it's easy enough to use <stdbool.hconditionally.

For example:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}

I guess gcc doesn't define that __STDC_VERSION__ by default
(and it's not a bug, right?). In particular, you can't put
that into a public header, and you need to be careful with
your compiler if you use this code.

But what's the point anyway? Using int as boolean type, and TRUE
and FALSE work well enough, and traditional

#ifndef TRUE
#define TRUE 1 /* or !0 or !FALSE or whatever you like */
#endif

doesn't break, does it? (Problems of Dumbos which write dimbo code
do not count, they will also do

#define false -1

anyway).

Regards,
Yevgen
Jan 17 '07 #39
Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
[...]
>But it's easy enough to use <stdbool.hconditionally.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.

The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.

Remove the extra #include and it's fine.
I guess gcc doesn't define that __STDC_VERSION__ by default
(and it's not a bug, right?). In particular, you can't put
that into a public header, and you need to be careful with
your compiler if you use this code.
The code is designed to work whether __STDC_VERSION__ is defined or
not. Any undefined symbols in a #if condition are replaced with 0.
But what's the point anyway? Using int as boolean type, and TRUE
and FALSE work well enough, and traditional

#ifndef TRUE
#define TRUE 1 /* or !0 or !FALSE or whatever you like */
#endif

doesn't break, does it? (Problems of Dumbos which write dimbo code
do not count, they will also do

#define false -1

anyway).
Sure, that works too. The point is to be consistent with C99 without
requiring a C99 implementation. If (yes, it's big if) C99 becomes as
widespread as C90 is now, the code can be simplified to use
<stdbool.hunconditionally. If you define macros "TRUE" and "FALSE",
and "true" and "false" are part of the language, then you'll have an
ugly mixture of different ways of doing the same thing.

--
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.
Jan 17 '07 #40
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>>
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}


You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.

Remove the extra #include and it's fine.
I guess the problem with this example is many compilers now have
stdbool.h, but not many claim to be C99, so __STDC_VERSION__ is less
than 199901L causing the compile error.

The extra include is a bit daft, it would makes the code fail to compile
if the implementation doesn't have stdbool.h.

--
Ian Collins.
Jan 17 '07 #41
Yevgen Muntyan wrote:
>
.... snip ...
>
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.

/* Standard defines of operators, usable on C90 up */
#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 17 '07 #42
CBFalconer <cb********@yahoo.comwrites:
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
bool is supposed to be a macro, too.
#define not !
#define and &&
#define or ||
#define xor ^
#endif
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield
Jan 17 '07 #43
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>Keith Thompson wrote:
[...]
>>But it's easy enough to use <stdbool.hconditionally.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}

You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.

Remove the extra #include and it's fine.
I put that extra include intentionally of course, to demonstrate
the problem. In real life you include someheader.h which includes
someotherheader.h which includes youhaveneverheardof.h which
includes stdbool.h.
>
>I guess gcc doesn't define that __STDC_VERSION__ by default
(and it's not a bug, right?). In particular, you can't put
that into a public header, and you need to be careful with
your compiler if you use this code.

The code is designed to work whether __STDC_VERSION__ is defined or
not. Any undefined symbols in a #if condition are replaced with 0.
Well, my point is that this code can easily cause problems. If
one really wants to use bool, true, and false, he should use something
more robust, e.g. what gnulib does - checks whether #include <stdbool.h>
works in configure, and then perform appropriate header dances.
Or just include <stdbool.h>, which will work too ;)

Best regards,
Yevgen
Jan 17 '07 #44
CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
>The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}

See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]

It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.

--------------------------------------------------
#include <stdbool.h>

#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif

int main (void)
{
}
--------------------------------------------------

Best regards,
Yevgen
Jan 17 '07 #45
Ben Pfaff <bl*@cs.stanford.eduwrites:
CBFalconer <cb********@yahoo.comwrites:
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;

bool is supposed to be a macro, too.
Yes. For (slightly) greater C99 compatibility, you might try:

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

except, of course, that "_Bool" is reserved to the implementation in
C90, and some compilers may support the _Bool keyword without claiming
C99 compliance. Oh, well.

--
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.
Jan 17 '07 #46
Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
[...]
>But it's easy enough to use <stdbool.hconditionally.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.
Remove the extra #include and it's fine.

I put that extra include intentionally of course, to demonstrate
the problem.
You might have mentioned that; I wouldn't have had to waste time
(admittedly not much) tracking down the bug that you introduced into
my code.
In real life you include someheader.h which includes
someotherheader.h which includes youhaveneverheardof.h which
includes stdbool.h.
If you want to write code that's compatible with both C90 and C99, you
don't write a "#include <stdbool.h>" without testing the
value of __STDC_VERSION__.

[snip]
Well, my point is that this code can easily cause problems. If
one really wants to use bool, true, and false, he should use something
more robust, e.g. what gnulib does - checks whether #include <stdbool.h>
works in configure, and then perform appropriate header dances.
All code can cause problems if it's misused.

Build-time configuration can work well too, but I prefer to put the
tests in the code itself *if* (a) it's possible to do so, and (b) it
doesn't make the code too ugly.
Or just include <stdbool.h>, which will work too ;)
Only if it exists, and only if the compiler (in its current mode)
recognizes the _Bool keyword.

--
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.
Jan 17 '07 #47
Yevgen Muntyan <mu****************@tamu.eduwrites:
CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
See the stdops.h header below. You should also test for __STDC__.
Use -W -Wall -ansi -pedantic with gcc.
[snip]

It (namely the code below) suffers from the very same problem.
__STDC_VERSION__ gets defined only if you use -std=c99, when it's
pointless. -ansi doesn't make it work.

--------------------------------------------------
#include <stdbool.h>

#ifndef stdops_h
#define stdops_h
#if defined(__STDC__) && (__STDC_VERSION__ >= 199901L)
/* The following from C99 - must define for C90 */
#include <stdbool.h /* define bool, true, false */
#include <iso646.h /* define not, and, or */
#else
#define false 0
#define true 1
typedef int bool;
#define not !
#define and &&
#define or ||
#define xor ^
#endif
#endif

int main (void)
{
}
Right. If you add an unconditional "#include <stdbool.h>" to code
that carefully tests whether C99 is supported, it will break if
compiled in non-C99 mode. So don't do that.

--
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.
Jan 17 '07 #48
Ian Collins wrote:
Keith Thompson wrote:
>Yevgen Muntyan <mu****************@tamu.eduwrites:
>>The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}

You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.

Remove the extra #include and it's fine.
I guess the problem with this example is many compilers now have
stdbool.h, but not many claim to be C99, so __STDC_VERSION__ is less
than 199901L causing the compile error.

The extra include is a bit daft, it would makes the code fail to compile
if the implementation doesn't have stdbool.h.
Not necessarily, e.g. gnulib actually creates stdbool.h if there is
no system one.
Or one could do

#ifdef HAVE_STDBOOL_H
#include <stdbool.h>
#else
/* the very same set of defines and typedefs */
#endif

Or one could indeed ignore systems which don't have stdbool.h, and still
have his code working on all systems he and his users have access to.

Regards,
Yevgen
Jan 17 '07 #49
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>Keith Thompson wrote:
>>Yevgen Muntyan <mu****************@tamu.eduwrites:
Keith Thompson wrote:
[...]
But it's easy enough to use <stdbool.hconditionally.
For example:
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
This "bool" typedef doesn't have exactly the same semantics as C99's
bool/_Bool type, but it's usable if you avoid writing writing
problematic code.
The following code doesn't compile with "gcc foo.c":

#include <stdbool.h>
#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif
int main (void)
{
return 0;
}
You added an extra "#include <stdbool.h>" outside the #if block. In
C99 mode, <stdbool.his included twice, which is harmless. In
non-C99 mode, it's included once, defining "false", "true", and "bool"
as macros, making the typedef illegal.
Remove the extra #include and it's fine.
I put that extra include intentionally of course, to demonstrate
the problem.

You might have mentioned that; I wouldn't have had to waste time
(admittedly not much) tracking down the bug that you introduced into
my code.
Sorry, I thought it was obvious, double #include <stdbool.hlooks
strange enough :)
>
> In real life you include someheader.h which includes
someotherheader.h which includes youhaveneverheardof.h which
includes stdbool.h.

If you want to write code that's compatible with both C90 and C99, you
don't write a "#include <stdbool.h>" without testing the
value of __STDC_VERSION__.

[snip]
>Well, my point is that this code can easily cause problems. If
one really wants to use bool, true, and false, he should use something
more robust, e.g. what gnulib does - checks whether #include <stdbool.h>
works in configure, and then perform appropriate header dances.

All code can cause problems if it's misused.
I do not think that #include <stdbool.his qualified as misusing
any code. If you can control all headers you are using (i.e. if you use
only standard headers and you believe your compiler is not buggy and
no standard header includes <stdbool.hwhen __STDC_VERSION__ is not
defined) then you probably can expect that code work. Otherwise, it can
easily break without doing any bad/wrong/strange/non-common stuff,
without any action from your side.

It is not true that "it's easy enough to use <stdbool.hconditionally"
using that code in a general situation (unless it's only about
programs which are "on-topic" here, programs that do not use
any headers which are not mentioned in standard; or only about those
cases when it's indeed easy enough).
Build-time configuration can work well too, but I prefer to put the
tests in the code itself *if* (a) it's possible to do so, and (b) it
doesn't make the code too ugly.
>Or just include <stdbool.h>, which will work too ;)

Only if it exists, and only if the compiler (in its current mode)
recognizes the _Bool keyword.
You sure need stdbool.h to exist to include it, but why would you need
_Bool?

Best regards,
Yevgen
Jan 17 '07 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.