Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Which numbers evaluate to true and false?

Reply
Thread Tools

Which numbers evaluate to true and false?

 
 
James McIninch
Guest
Posts: n/a
 
      10-04-2005
Paminu wrote:

> As I remember if(1) evaluates to true and all other numbers including 0
> evaluate to false.


That would be 0 is false and all other true.


> But where do I find out about this for sure?? I have looked through K&R,
> all the C for dummies books and various other C programming books but
> nowhere there is a mention on what a number in an if statement evaluates
> to.
>
> Is this some kind of big secret?


No secret. Any C language reference will tell you:

http://www.lysator.liu.se/c/bwk-tutor.html#if

--
Remove '.nospam' from e-mail address to reply by e-mail
 
Reply With Quote
 
 
 
 
August Karlstrom
Guest
Posts: n/a
 
      10-05-2005
Skarmander wrote:
> Skarmander wrote:
>
>> Keith Thompson wrote:
>>
>>> Skarmander <(E-Mail Removed)> writes:
>>> [...]
>>>
>>>> Yes: C has no boolean type.
>>>
>>>
>>>
>>>
>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>

>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>> quite right.
>>

>
> You know, for some reason the C99 bool really annoys me. *Now* they fix
> things? Too late. Leave it alone. Introducing size_t to provide a new
> level of abstraction was a good thing. But bool? Not worth the bother,
> with the backwards compatibility tricks they have to pull.
>
> It ticks me off because I'd *like* to use "real" booleans, but if that
> means requiring a C99 compiler, then no thanks, it's not worth it.
> Classic chicken and egg story.


The real virtue of the bool type is that it conveys more information
compared to an int used as a boolean type. You never need comments as
"non-zero if... and zero if...". You still need to know though that it
is really just an int and that zero is interpreted as `false' and
non-zero as `true'.


August
 
Reply With Quote
 
 
 
 
August Karlstrom
Guest
Posts: n/a
 
      10-05-2005
Skarmander wrote:
> Skarmander wrote:
>
>> Keith Thompson wrote:
>>
>>> Skarmander <(E-Mail Removed)> writes:
>>> [...]
>>>
>>>> Yes: C has no boolean type.
>>>
>>>
>>>
>>>
>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>

>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>> quite right.
>>

>
> You know, for some reason the C99 bool really annoys me. *Now* they fix
> things? Too late. Leave it alone. Introducing size_t to provide a new
> level of abstraction was a good thing. But bool? Not worth the bother,
> with the backwards compatibility tricks they have to pull.


What backwards compatibility tricks?


August
 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      10-05-2005
August Karlstrom wrote:
> Skarmander wrote:
>
>> Skarmander wrote:
>>
>>> Keith Thompson wrote:
>>>
>>>> Skarmander <(E-Mail Removed)> writes:
>>>> [...]
>>>>
>>>>> Yes: C has no boolean type.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>>
>>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>>> quite right.
>>>

>>
>> You know, for some reason the C99 bool really annoys me. *Now* they fix
>> things? Too late. Leave it alone. Introducing size_t to provide a new
>> level of abstraction was a good thing. But bool? Not worth the bother,
>> with the backwards compatibility tricks they have to pull.

>
>
> What backwards compatibility tricks?
>

Rather than just adding "bool", "true" and "false" to the language
(which would break many programs even if they use the "right"
definitions), we've got a new type called _Bool, and if you want to have
it named "bool", you #include <stdbool.h>. Which you'll always do,
unless of course you have to be compatible with an existing unit that
defines "bool".

That's what I call a backwards compatibility trick. (OK, so maybe it's
just one.) _Bool will also be the first keyword beginning with an
underscore.

I don't know. I'm sure it works and is a very practical solution. It's
still ugly to me.

S.

 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      10-05-2005
August Karlstrom wrote:
> Skarmander wrote:
>
>> Skarmander wrote:
>>
>>> Keith Thompson wrote:
>>>
>>>> Skarmander <(E-Mail Removed)> writes:
>>>> [...]
>>>>
>>>>> Yes: C has no boolean type.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> C99 has _Bool (called "bool" with "#include <stdbool.h>").
>>>>
>>> Pfff. I sort-of semi-deliberately overlooked that, but yes, you're
>>> quite right.
>>>

>>
>> You know, for some reason the C99 bool really annoys me. *Now* they fix
>> things? Too late. Leave it alone. Introducing size_t to provide a new
>> level of abstraction was a good thing. But bool? Not worth the bother,
>> with the backwards compatibility tricks they have to pull.
>>
>> It ticks me off because I'd *like* to use "real" booleans, but if that
>> means requiring a C99 compiler, then no thanks, it's not worth it.
>> Classic chicken and egg story.

>
>
> The real virtue of the bool type is that it conveys more information
> compared to an int used as a boolean type. You never need comments as
> "non-zero if... and zero if...". You still need to know though that it
> is really just an int and that zero is interpreted as `false' and
> non-zero as `true'.
>

Two points. First, yes, I understand the virtue of "bool". Had it been
part of C in the first place, I would be its staunchest defender. It
certainly wouldn't have been anything new: Algol 60 set the example. I
guess K&R just didn't think it was worth including as a separate type --
probably a quirk from C's one-type origins.

Second, exactly because "you still need to know though that it is really
just an int and that zero is interpreted as `false' and non-zero as
`true'", it strikes me as terribly after-the-fact. We can't suddenly
forget about C's booleans-that-are-not-booleans rule -- we have to drag
that nonsense around even with a builtin bool type. The benefit gained
from making your intentions clearer is great, but C has never been a
language that promoted clarity of expression, so I'm not overwhelmed.

S.
 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      10-05-2005
August Karlstrom wrote:
> Skarmander wrote:


> The real virtue of the bool type is that it conveys more information
> compared to an int used as a boolean type. You never need comments as
> "non-zero if... and zero if...". You still need to know though that it
> is really just an int and that zero is interpreted as `false' and
> non-zero as `true'.


To describe something that contains less information as conveying more
is at best silly. Nor do you need such comments any more or any less
with a bool type. Tell me why (I) is any more or less in need of such
comments than (II).

(I)
{
bool equalp();
/* ... */
if (equalp()) { /* ... */ }
/* ... */
if (!equalp()) { /* ... */ }

}


(II)
{
int equalp();
/* ... */
if (equalp()) { /* ... */ }
/* ... */
if (!equalp()) { /* ... */ }

}
 
Reply With Quote
 
Anonymous 7843
Guest
Posts: n/a
 
      10-05-2005
In article <4343ddf7$0$11067$(E-Mail Removed)4all.nl>,
Skarmander <(E-Mail Removed)> wrote:
>
> Rather than just adding "bool", "true" and "false" to the language
> (which would break many programs even if they use the "right"
> definitions), we've got a new type called _Bool, and if you want to have
> it named "bool", you #include <stdbool.h>. Which you'll always do,
> unless of course you have to be compatible with an existing unit that
> defines "bool".


It feels odd to say this, but I think I would have preferred
that bool, true, and false be always defined in C99, and modules
that use definitions incompatible with this could #include <nostdbool.h>
(or maybe a #define or #pragma) to escape from this.

Actually, it would be neat to have a silent compatibility mode where
modules could create and use their own defininitions of true, false and
bool that are roughly compatibile with stdbool without complaint.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-05-2005
Skarmander <(E-Mail Removed)> writes:
[...]
> That's what I call a backwards compatibility trick. (OK, so maybe it's
> just one.) _Bool will also be the first keyword beginning with an
> underscore.


_Complex and _Imaginary were introduced at the same time.

I agree that syntax is ugly, and it's not nearly as good as it would
have been if it had been in the language in the first place, but IMHO
it's still an improvement.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      10-05-2005
Keith Thompson wrote:
> Skarmander <(E-Mail Removed)> writes:
> [...]
>
>>That's what I call a backwards compatibility trick. (OK, so maybe it's
>>just one.) _Bool will also be the first keyword beginning with an
>>underscore.

>
>
> _Complex and _Imaginary were introduced at the same time.
>

Ah, yes. The direly needed complex types. But I'll leave that alone;
I'm not a numerics type so I don't consider myself qualified to judge
its merits.

> I agree that syntax is ugly, and it's not nearly as good as it would
> have been if it had been in the language in the first place, but IMHO
> it's still an improvement.
>

When C99 is finally widely established, it probably will be.

S.
 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      10-05-2005
Martin Ambuhl wrote:
> August Karlstrom wrote:
>
>> Skarmander wrote:

>
>
>> The real virtue of the bool type is that it conveys more information
>> compared to an int used as a boolean type. You never need comments as
>> "non-zero if... and zero if...". You still need to know though that it
>> is really just an int and that zero is interpreted as `false' and
>> non-zero as `true'.

>
>
> To describe something that contains less information as conveying more
> is at best silly. Nor do you need such comments any more or any less
> with a bool type. Tell me why (I) is any more or less in need of such
> comments than (II).
>
> (I)
> {
> bool equalp();
> /* ... */
> if (equalp()) { /* ... */ }
> /* ... */
> if (!equalp()) { /* ... */ }
>
> }
>
>
> (II)
> {
> int equalp();
> /* ... */
> if (equalp()) { /* ... */ }
> /* ... */
> if (!equalp()) { /* ... */ }
>
> }


I assume the p suffix stands for "predicate", right? This is a kind of
Hungarian notation that is common practice in languages that lacks a
boolean type, e.g. Emacs lisp. With a boolean type there's no need for
obscure naming, we just go:

{
bool equal();
/* ... */
if (equal()) { /* ... */ }
/* ... */
if (!equal()) { /* ... */ }

}


August
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[False,True] and [True,True] --> [True, True]????? bdb112 Python 45 04-29-2009 02:35 AM
evaluate NULL to a pointer which a CONST pointer points to G C++ 3 01-08-2007 04:22 PM
Why would this IF statement evaluate as TRUE? Steve Javascript 5 12-07-2004 07:02 AM
Can't get a db value to evaluate to TRUE...why? darrel ASP .Net 8 02-11-2004 01:43 PM
NULL: Is it guaranteed to evaluate 'not true' Mark A. Odell C Programming 19 09-30-2003 01:51 PM



Advertisments