[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: Problem with +numberWithBool: ?
From: |
Manuel Guesdon |
Subject: |
Re[2]: Problem with +numberWithBool: ? |
Date: |
Sat, 31 Jan 2004 01:08:01 +0100 (CET) |
On Sat, 31 Jan 2004 00:04:45 +0100 "Pascal J.Bourguignon" <address@hidden>
wrote:
>| It's a C (or Objective-C) question: does a==b (or a<b, etc) return 0/1
>| or 0/possibly anything else than 0 ?
>|
>| On 680x0 processors, the instructions that build boolean values give 0
>| and 0xff ((char)(-1)). All C compilers I've see on these processors
>| always take care to mask it off to 0/1.
>|
>| I don't have my ANSI-C references at hand, but if it's said that
>| boolean producing operators always return 0 or 1, then there is no
>| problem, returning a boolean expression will return a BOOL (or a
>| bool).
>|
>|
>| In any case, that's one more reason why it's better to write
>| if(condition) rather than if(condition==YES).
A reference:
http://www.lysator.liu.se/c/c-faq/c-8.html
<<
8.2: Isn't #defining TRUE to be 1 dangerous, since any nonzero value is
considered "true" in C? What if a built-in boolean or relational operator
"returns" something other than 1?
It is true (sic) that any nonzero value is considered true in C, but this
applies only "on input", i.e. where a boolean value is expected. When a
boolean value is generated by a built-in operator, it is guaranteed to be 1 or
0. Therefore, the test
if((a == b) == TRUE)
will work as expected (as long as TRUE is 1), but it is obviously silly. In
general, explicit tests against TRUE and FALSE are undesirable, because some
library functions (notably isupper, isalpha, etc.) return, on success, a
nonzero value which is not necessarily 1. (Besides, if you believe that "if((a
== b) == TRUE)" is an improvement over "if(a == b)", why stop there? Why not
use "if(((a == b) == TRUE) == TRUE)"?) A good rule of thumb is to use TRUE and
FALSE (or the like) only for assignment to a Boolean variable or function
parameter, or as the return value from a Boolean function, but never in a
comparison.
>>
Manuel
--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement - 93200 Saint-Denis - France
Tel: +33 1 4940 0999 - Fax: +33 1 4940 0998
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), (continued)
- Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?), Alexander Malmberg, 2004/01/31
- Re: Problem with +numberWithBool: ?, Alexander Malmberg, 2004/01/30
- Re: Problem with +numberWithBool: ?, Nicola Pero, 2004/01/30
- Re: Problem with +numberWithBool: ?, Alexander Malmberg, 2004/01/30
- Re: Problem with +numberWithBool: ?, Philippe C.D. Robert, 2004/01/30
- Re: Problem with +numberWithBool: ?, Pascal J . Bourguignon, 2004/01/30
- Re: Problem with +numberWithBool: ?, Richard Frith-Macdonald, 2004/01/30
- Re: Problem with +numberWithBool: ?, Pascal J . Bourguignon, 2004/01/30
- Re[2]: Problem with +numberWithBool: ?,
Manuel Guesdon <=