"Jim Langston" <tazmaster@rocketmail.com> writes:
"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln64kvucok.fsf@nuthaus.mib.org...
"siska" <stephenwvickers@hotmail.com> writes:
Keith Thompson wrote:
And if you think that "wait_for_something == true" is clearer than
"wait_for_something", wouldn't "(wait_for_something == true) == true"
be better yet?
See section 9 of the comp.lang.c FAQ, <http://www.c-faq.com/>.
I treat that as preference. What is the difference between:
if ( wait_for_something )
and
if ( wait_for_something == true )
The biggest difference is that me, looking at this code, immediately know
in
the second form that wait_for_something is a boolean value. In the first
form I don't know if it's an integer or char or perhaps even something
else.
I'm one who believe in self documenting code.
Yes, I would probably write
if ( wait_for_something )
only if wait_for_something was obviously a boolean value.
The difference is that they don't mean the same thing.
This:
if (wait_for_something)
is *not* equivalent to this:
if (wait_for_something == true)
It's equivalent to this:
if (wait_for_something != 0)
If you restrict yourself to _Bool (C99) or bool (C++), you can
probably get away with assuming that the value will always be 0 or 1.
But if wait_for_something is an int being used to indicate a
condition, any non-zero value is treated as true; the is*() function
in <ctype.h>, for example, can return any non-zero value for true.
Note that this is cross-posted to comp.lang.c and comp.lang.c++.
Since C++ has had a built-in bool type longer than C has, this
argument may not be as strong for C++ as it is for C. But equality
comparisons to true or false are still a bad idea.
Yes. In C I wouldn't compare against anything, since C doesn't have a true
boolean value. I responded to this in c.l.c++ and didnt' realize it was
and, only a bitwise and.