TRUE and FALSE

Brad Appleton brad at SSD.CSD.HARRIS.COM
Sat Sep 1 00:06:26 AEST 1990


>And defining TRUE and FALSE tends to lead, eventually, to some
>maintenance programmer who's just (almost) learned C writing
>
>   if (flag == TRUE)
>
>which of course doesn't work at all the way it looks.  (Though I'll
>admit it reads well: "if flag is true...")  IMHO, any "improvement"
>that would lead a novice into this sort of error is a step backwards.
>
>Of course, this is now the <n+1>st rehashing of this issue in this
>newsgroup, and it's essentially become a religious war.

I thought the whole point of having a boolean type was so that one
could write:

	if ( flag1  &&  !flag2 )

instead of

	if ( flag1 == TRUE  &&  flag2 == FALSE ).

TRUE and FALSE have no place being part of this type of comparison in 
any programming language that provides a boolean type; they are only
needed for assignment. SO why do some people insist on putting them 
in logical comparisons - its redundant.

Maybe instead of #defining or enum'ing TRUE and FALSE we should
encourage doing something like:

	#define  SET(flag)   flag = 1  /* or -1 or !0 or whatever */
	#define  CLEAR(flag) flag = 0

and if you want to get fancy:

	#define  TOGGLE(flag) flag = (flag) ? 1 : 0

(or whatever macro names you prefer) and then we would never be tempted
to use them in a comparison.

It just bothers me when I see (flag == FALSE) instead of (!flag).
I guess this is the n+2 rehashing of this tripe!

______________________ "And miles to go before I sleep." ______________________
 Brad Appleton        brad at travis.ssd.csd.harris.com   Harris Computer Systems
                          ...!uunet!hcx1!brad          Fort Lauderdale, FL USA
~~~~~~~~~~~~~~~~~~~~ Disclaimer: I said it, not my company! ~~~~~~~~~~~~~~~~~~~



More information about the Comp.lang.c mailing list