TRUE and FALSE
M.T.Russell
mtr at ukc.ac.uk
Tue Sep 4 23:08:38 AEST 1990
The reason for using TRUE and FALSE rather than 1 and 0 is simple: it
lets you say what you mean. Someone once said that `GOSUB 9000' was
the most dismal statement in the whole of computing. In my opinion
`boolvar = 1;' is in the same class.
To the people complaining about `if (x == TRUE)': YOU ONLY USE `TRUE' AND
`FALSE' FOR ASSIGNMENT AND PARAMETER PASSING. It's a fairly simple rule.
I'd be interested to see some experiments with adding a `bool' type to a
C compiler (gcc?), with the following semantics:
- bool has the same size and representation as int.
- the comparison operators yield bool as the result type.
- the `&&', `||' and `!' operators demand bool operands and
yield a bool result. The ?: operator demands bool as its
first operand. The only other operators that take bool
operands are `!=', `==' and `&' (address of).
- `if', `do/while', `while' and `for' demand a bool expression
as the test. Note that `if (ptr)' is still allowed by the
implicit rewrite to `if (ptr != 0)'.
- assignment and comparison between bool and arithmetic types
is illegal without a cast, except for assignment to a bool
lvalue of an integral constant expression with the value 0 or 1.
This would provide some useful extra type checking, especially now that
we have function prototypes. If `typedef int bool;' was allowed as a
special case, then code portability wouldn't be affected.
One weakness of this scheme is that it forces bool variables to take
the same space as an int. I'm not sure whether adding `shortbool'
and `charbool' types (with appropriate conversion rules) would be worth
the additional complexity. Programmers can always use casts.
BTW: these rules would reject `bool gotdigit = isdigit(c)', and rightly.
Mark Russell
More information about the Comp.lang.c
mailing list