Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!gem.mps.ohio-state.edu!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-sdd!apollo!lsmith
From: lsmith@apollo.HP.COM (Lawrence C. Smith)
Newsgroups: comp.lang.c++
Subject: Re: Time to standardize "true" and "false"
Keywords: true false C C++
Message-ID: <45fe1457.1199f@apollo.HP.COM>
Date: 2 Oct 89 20:25:00 GMT
References: <13730@well.UUCP> <9464@attctc.Dallas.TX.US> <2142@dataio.Data-IO.COM>
Reply-To: lsmith@apollo.HP.COM (Lawrence C. Smith)
Distribution: comp
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 101
In article <2142@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
>In article <9464@attctc.Dallas.TX.US> wjf@attctc.Dallas.TX.US (Jesse Furqueron) writes:
>, nagle@well.UUCP (John Nagle) writes:
><< I would like to suggest that the time has come to standardize the
><< Boolean values in C. Most programs have definitions of these, but they
><< differ and clash.
>
>What's the point? !0 == 1. Period. It is not going to change. !0 is not
>more portable or more readable.
Sadly, many C hackers just don't realize how important a clear, readable style is.
This last comment reminds of the other fellow who also felt that, because ints *could*
be used for booleans then that was *good* and there was no point making things more
"complicated". Perhaps these people would also like BLISS, which reduces the number
of essential data types to just one...
>
>I used to extensively use:
> typedef int bool;
> #define TRUE 1
> #define FALSE 0
>I eventually gave this up because:
>1. Name space collisions with other people's code.
>2. Frequent confusion of whether TRUE meant !=0 or if it really meant 1.
I use something like this:
typedef int flag;
#define YES (1==1)
#define NO (1==0)
#define OKAY(x) ((x) != 0)
The use of YES, NO, OKAY and flag do not seem to generate much conflict with other
people's choices, and the YES and NO macros are guaranteed portable (and I obviously
depend on the optimizer to turn (1==1) into the appropriate internal TRUTH value).
Since YES and NO always equate to whatever internal values the compiler likes, and
since most compilers *will* do constant folding, these work out pretty efficiently.
Also, I can now save boolean expressions:
flag foo;
foo = A == B;
With the fairly certain knowledge that if(foo) (or the somewhat ridiculous
if(foo == YES)) will work consistantly and correctly. OKAY is used for old
C code:
foo = OKAY(strcmp("fubar",some_silly_string))
if(foo) ...
It's not as good as a rigorously defined built-in type with compiler checking and
the like, buts it *is* better than just using 0 and 1 with ints.
> Note that functions like isalpha() return !=0 or 0, not 1 or 0. This
> means that if you wish to precisely use TRUE/FALSE, you have to write code
> like
> condition = (isalpha(c) != 0);
> which is an efficiency problem.
It is like fun. I will grant you that C has twelve ways of doing something because
they are, in theory, compiled differently and that some ways are more efficient than
others in certain contexts and that the programmer has the power to choose. But this
is the modern world!!! In this enlightened day and age, we know that 90% of the
execution time is in 10% of the code, and that optimizing code executed once buys
nothing. In this enlightened day and age, we know that optimizers will fold, spindle
and mutilate our code, and that most of the time the optimizers know more about
efficient instruction sequences on CPU x than we do, and that's the way it should be.
In this enlightened day and age, we know that condition = (isalpha(c) != 0) will
very seldom be an efficiency problem, even assuming the compiler really compiles it
that way.
>P.S. One of my pet peeves is code like:
> #ifdef notdefined
>instead of
> #if 0
>For the former, I have to grep all the c, h and makefiles to make sure
>notdefined is never defined. For the latter, there can be no problem.
>Ditto for stuff like
> while (ALWAYS)
> loop_forever
>instead of
> while (1)
You choose your idiom and you use it. Where I come from, people who write
while (1) would be castigated, flagellated and fumigated for not having written
for(;;). In other places, you would be taken to task for not writing while(1),
or whatever. C has too many different ways of doing things for any of them to
be universal without enforcement from training institutions, of which we ain't
got. for(;;) was the Stony Brook way, so that's what I learned. Is it still that
way? Who knows. It might be, if the same guy is teaching the course. Or maybe
they have a new former Berkley guy who likes while(1) or while (1). Of course,
they might also have a new wave guy who likes "#define loop while(1) ... loop ..."
or even a FORTRAN retread who simply does a "go to loop" at the bottom of his
loop.
If you want consistant, use Pascal.
--
Larry Smith
Internet: lsmith@apollo.hp.com
UUCP: {decvax,mit-eddie,umix}!apollo!lsmith