TRUE and FALSE

Jimmy Hu jimmy at tybalt.caltech.edu
Fri Sep 7 10:37:09 AEST 1990


In article <5409 at harrier.ukc.ac.uk> mtr at ukc.ac.uk (M.T.Russell) writes:
>
>I'd make a couple of changes to my scheme on reflection: I'd disallow
>assignment of 0 and 1 to bool variables, and make TRUE and FALSE keywords.
>I'd also turn on a macro __BOOL__ to indicate that the extension was
>there, so that applications could say:
>
>	#ifndef __BOOL__
>	typedef int bool;
>	#define TRUE 1
>	#define FALSE 0
>	#endif

There only purposes for a boolean type in C are for "increased
readability" and "stronger type-checking." But for me, personally,
the reason I use C instead of say, Pascal, is that I don't want all
these restrictions. I don't want to hide the fact that the "booleans"
I use are actually ints. I LIKE the fact that C's "booleans" are ints,
and I use that fact when I write something like:

d = (a==b)*c;         /* Just a contrived example to set d to 0 or c */

I like the fact that all nonzero values are considered true. For
instance, when I have an int in which I may or may not have set
certain bits, and I want to know if I have set any, I can just
write "if (flags)" and not "if (flags != 0)."  Or if I want to check
a certain bit, I can write "if (flags & 0x0800)" and not
"if ((flags & 0x0800) != 0)."

Now I have no objection to people who use TRUE and FALSE for better
readability as long as they know what they're doing. And if they want
to construct a boolean type with bool.h, that's also fine with me. But
as for the idea of making a standard boolean type for C, I'd have to
say that this is going a bit too far, since it would make life difficult
to the many programmers who actually make good use of ints as booleans.
Since most languages compile booleans to ints anyways, why not use that
extra space for your own purposes?

About the macros that put out a 200000+ character definition, I think
that this is just plain silly. Most of those definitions could have been
shortened by defining them on C's operators instead of on each other. Why
make the compiler spend minutes deciphering "ISFALSE(x)" and substituting
a monstrously convoluted synonym for (!(x))? I mean, this is C, so use it
to your full advantage, right? You don't have to use the more restrictive
Pascal-like or the more verbose Lisp-like constructs! I think other C
programmers looking at your code will understand what you mean even when
you use obscure things like "if (x)" instead of "if ISTRUE(x)." :-)

--
----------------------------------------------------------------------
Jimmy Hu                                      jimmy at tybalt.caltech.edu
----------------------------------------------------------------------



More information about the Comp.lang.c mailing list