Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.lang.c
Subject: Re: TRUE and FALSE
Message-ID: <898@mwtech.UUCP>
Date: 3 Sep 90 23:36:46 GMT
References: <11215@alice.UUCP> <514@demott.COM> <664@csource.oz.au> <585@quad.sialis.mn.org>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 83

In article <585@quad.sialis.mn.org> dts@quad.sialis.mn.org (David T. Sandberg) writes:
>In article <664@csource.oz.au> david@csource.oz.au writes:
[and many many others wrote about their preference for #defining
TRUE and FALSE over simply using good ol' plain 1 and 0]

I quote the following only as an example:
>My two cents: I define FALSE as 0 and TRUE as 1 on a regular basis,
>but only use [... followed by about 10 more lines of rules when and
 when not to use TRUE and FALSE in statements]

People! Aren't you realizing what you are doing here?

K&R tried to make this very easy with C ... they LEFT OUT out a
"boolean" or "logical" datatype and gave *very simple* rules for
using int for that purpose. You need no more than these two
sentences to completly describe the behaviour:

	In every context where the further execution depends on
	a truth value of some expression, the value 0 is taken to
	mean FALSE and any other value is taken to mean TRUE.

	In any context where the execution of a builtin operator
	yields a truth value, this value is 0 for FALSE and 1 for
	TRUE.

But what are YOU doing: You clutter up this beautiful and easy to follow
mapping between int-s and truth values with new #defines or enum-s and
now of course you need additional rules, in which contexts your
augmentations may be safely used and where they are dangerous. In
the last an final result, whoever want's to use your TRUE and FALSE
must nevertheless understand the *whole* story, until he or she can
do it right all the time.

But isn't a claimed goal of some of you to make C easier to write by
defining TRUE and FALSE? No, it should only be easier to read?
So let me ask you: Why should anybody read your code if this person
hasn't sooner or later to modify this code or take at least part of
it as a template for own work? And how have you made sure that the
readers have grasped *your* strict rules when and when not to use
TRUE and FALSE and will apply it correctly?

Now, if you think it's such a bad idea to set a variable which has
only to reflect two states to the values 0 and 1 why don't you call
the formal constants somthing like SET, YES, ON, SUCCESS, ... (and
their counterparts CLEAR, NO, OFF, FAILURE, ...)?  Is it because
most of you (still) grew up with PASCAL?

And a final word to the ones who advocate "strong typing": You should
clearly vote for differently typed truth values (a la "new ...." in
ADA) - which of course are not supported by the C-compiler, but can
at least be done for "the eyes of the reader": If you are reluctant when
it comes to mixing (integer) numbers with truth values, you should
clearly vote for *differently named* constants for different sorts
of truth values. Take the following example:

	enum bool { FALSE, TRUE };
	bool fast_tty, can_scroll;
	.....
	/* if TTY is fast, we assume it can scroll */
	can_scroll = fast_tty;

Isn't this a bit like substituting apples for oranges? Shouldn't we rather
write:
	can_scroll = (fast_tty == TRUE) ? TRUE : FALSE;

If you strongly favour the latter for some reason, why not clarify it
further:

	enum { SLOW_TTY, FAST_TTY } tty_speed;
	enum { NO_SCROLL, CAN_SCROLL } scroll_mode;
	...
	scroll_mode = (tty_speed == FAST_TTY) ? CAN_SCROLL : NO_SCROLL;

Here we completly avoid TRUE and FALSE (of course we have to think hard
and invent other "good" names for our purpose), but we can later make
easly additions, eg.

	enum { NO_SCROLL, JUMP_SCROLL, SMOTH_SCROLL } scroll_mode;

And those of you who are paid based on how much lines of code you
write per month should also feel comfortable with this proposual :-)
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83