Path: utzoo!attcan!uunet!island!grenada!christmas!rtm
From: rtm@christmas.UUCP (Richard Minner)
Newsgroups: comp.lang.c
Subject: more on TRUE and FALSE (sorry) with JOKES
Message-ID: <9@christmas.UUCP>
Date: 14 Sep 90 23:00:48 GMT
Organization: Island Graphics, Sacramento, California
Lines: 74


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 ||