more on TRUE and FALSE (sorry) with JOKES
Richard Minner
rtm at christmas.UUCP
Sat Sep 15 09:00:48 AEST 1990
This whole discussion of #defining TRUE and FALSE reminded me
of one of my favorite fortunes of all time:
The primary purpose of the DATA statement is to give names to
constants; instead of referring to pi as 3.141592653589793 at every
appearance, the variable PI can be given that value with a DATA
statement and used instead of the longer form of the constant. This
also simplifies modifying the program, should the value of pi change.
-- FORTRAN manual for Xerox Computers
I've read it a dozen times or more and it still makes me laugh.
Personally, I like to use:
#define 0 0
#define 1 1
Just to be sure...
Actually, I use TRUE and FALSE, but only for assignments and return
values, honest. ;-)
The construct:
if (boolvar == TRUE)
is just plain silly, even in pascal where it's `safe'. Get real.
(And the `what about novice programmers' argument is specious;
a novice programmer might do anything. Besides, I'd bet a novice
would be at least as likely to screw up code that uses `flag = 1'
and `return 1'.)
Gee, if you want to be really really clear, why not use:
#define TRUE 1
#define REALLY_TRUE 1
#define TRUE_AS_CAN_BE 1
#define FALSE 0
#define REALLY_FALSE 0
#define EVER_SO_FALSE 0
if (((boolvar == TRUE) == REALLY_TRUE) == TRUE_AS_CAN_BE)
...
On a more serious note, one drawback of not having a real
boolean type is that you can't blithely go
if (boolvar1 == boolvar2)
to mean
if ((boolvar1 && boolvar2) || (!boolvar1 && !boolvar2))
which is a (small) shame.
Something I'd like to see more of is the `boolify' operator: !!
I've almost written `if (!!boolvar1 == !!boolvar2)' on occasion
but I was afraid it might be too strange. However, I have used
`boolvar = !!intvar' at times (mainly as a reminder to myself).
(I also worry that a broken compiler might erroneously toss out
!!'s, similar to the &&&*** bug discussed.)
For those who still don't like TRUE and FALSE, you might consider
using `1/*true*/' and `0/*false*/' (you could even bind them to
editor macros, golly), as in:
is_so = 1/*true*/;
aint_so = 0/*false*/;
return 1/*true*/;
Ugly but clear. I tried it for a while, and still use it sometimes
when TRUE and FALSE aren't around. More to the point, it's good
practice to give boolean variables and functions `predicate' names,
e.g. use `is_init' instead of just `init', and is_valid(thing)
instead of check(thing). (But then there are the is*() ctype
functions that return arbitrary non-0 values for true. Oh well,
I guess it's still C...)
--
Richard Minner || {uunet,sun,well}!island!rtm (916) 736-1323 ||
|| Island Graphics Corporation Sacramento, CA ||
More information about the Comp.lang.c
mailing list