By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,828 Members | 2,241 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,828 IT Pros & Developers. It's quick & easy.

TRUE/FALSE values: Point / Counterpoint

Expert 100+
P: 2,400
A side-discussion developed in the Wierd Visual Studio Problem thread. Rather than continue to hijack that topic, I've created a new thread and copied over the relevant postings.
@Andr3w
Mar 20 '09 #1
Share this Question
Share on Google+
14 Replies


Expert 100+
P: 2,400
@donbock
@donbock
....................
Mar 20 '09 #2

Expert 100+
P: 2,400
@Andr3w
....................
Mar 20 '09 #3

Expert 100+
P: 2,400
@donbock
....................
Mar 20 '09 #4

Expert 100+
P: 2,400
@Andr3w
....................
Mar 20 '09 #5

Expert 100+
P: 2,400
I don't think this is an issue of coding style. Consider the following code:
Expand|Select|Wrap|Line Numbers
  1. #define TRUE 0
  2. #define FALSE 1
  3.  
  4. int isDone;
  5. ...
  6. if (isDone) {
  7.    <something that only happens when you're done>
  8. }
If you set isDone to TRUE then the conditional code doesn't execute; if you set isDone to FALSE then the conditional code executes. This is counterintuitive behavior. You get similar unexpected behavior if you use isDone as the condition to terminate a loop.

C99 added <stdbool.h> as a new standard header. This header is required to contain something equivalent to:
Expand|Select|Wrap|Line Numbers
  1. #define true 1
  2. #define false 0
The chances of confusion and error abound when "true" means the same thing as "FALSE".
Mar 20 '09 #6

Andr3w
P: 42
Well, I am careful with my code in order to get it working and bug free. I have a coding style and you have yours. It's a matter of preference and I know this behavior is present if I set the values that way...

Anyway really I don't think there is a point continuing this really as there is no argument to begin with, or at least I think so
Mar 20 '09 #7

Expert 10K+
P: 11,448
@donbock
That makes -2 points (-1 for each semicolon). Next!

kind regards,

Jos
Mar 20 '09 #8

Andr3w
P: 42
weeee thanks for pointing it out...stupid typos are a common mistake...for all programmers...

Anyway I'll be more careful next time...to avoid typos

be safe
Mar 20 '09 #9

Expert 10K+
P: 11,448
@Andr3w
Also better turn those definitions around, as in:

Expand|Select|Wrap|Line Numbers
  1. #define TRUE 1
  2. #define FALSE 0
  3.  
I, for one, rely on the fact that TRUE is a non-zero value and 1 to be exact; I like to use that value in arithmetic expressions when appropriate. Also I expect a true expression to succeed in a conditional expression. Even more I want the following to succeed as well:

Expand|Select|Wrap|Line Numbers
  1. if ((1+1 == 2) == TRUE) { ... }
  2.  
kind regards,

Jos
Mar 20 '09 #10

weaknessforcats
Expert Mod 5K+
P: 9,197
Defining TRUE = 1 and FALSE = 0 won't work. Never has worked. Remember that 25 is also TRUE.

You need to do it this way:
Expand|Select|Wrap|Line Numbers
  1. #define FALSE  0
  2. #deifne TRUE  !FALSE
Mar 20 '09 #11

Expert 10K+
P: 11,448
@weaknessforcats
True (sic) but the canonic integer value for 'true' equals 1. Read the Standard (e.g. for the ! operator):

The result of the logical negation operator ! is 0 if the value of
its operand compares unequal to 0, 1 if the value of its operand
compares equal to 0. The result has type int . The expression !E is
equivalent to (0==E) .
Here's another (more realistic) example:

Expand|Select|Wrap|Line Numbers
  1. #define SIGN(x) (((x) > 0) - ((x) < 0))
  2.  
I can use that integer value in integer expressions if I want to so I expect any symbolic value TRUE to equal 1.

kind regards,

Jos
Mar 20 '09 #12

weaknessforcats
Expert Mod 5K+
P: 9,197
I have no idea about canonical or not but this doesn't work as expected:

Expand|Select|Wrap|Line Numbers
  1. #define TRUE 1
  2. #define FALSE 0
  3.  
  4. int data = 25;
  5. if (data == TRUE)
  6. {
  7.         printf("It's true\n");
  8. }
TRUE has to be !FALSE
Mar 20 '09 #13

Expert 10K+
P: 11,448
@weaknessforcats
Then it still doesn't work; you are mixing up the (conceptual) boolean domain with the integer domain. btw !FALSE will be equal to 1.

kind regards,

Jos
Mar 20 '09 #14

Expert 100+
P: 2,400
I'm pretty sure that the Standards all guarantee that any logical expression will evaluate to precisely "0" or "1" so JosAH's SIGN macro is portable and safe.

On the other hand, conditional instructions (if, for, while) consider all nonzero argument values to be equivalent. I'm paranoid that a boolean variable might somehow be assigned a nonzero value other than "1". If that were to happen then explicit comparisons to canonical TRUE and FALSE values would see a value that was neither true nor false, possibly resulting in some weird inconsistent path through a series of conditionals.

I don't allow my team to perform comparisons to a canonical TRUE value. I have them either treat boolean variables as predicates or perform all comparisons against the canonical FALSE value.
Expand|Select|Wrap|Line Numbers
  1. void func1(int isThatCondition) {
  2.    if (isThatCondition) {...}
  3. }
  4.  
  5. void func2(int isThatCondition) {
  6.    if (isThatCondition != FALSE) {...}
  7. }
My preference is to use booleans as predicates, being careful that the variable names include an appropriate existence verb.
Mar 20 '09 #15

Post your reply

Sign in to post your reply or Sign up for a free account.