Maybe I got this idea from some other language, but I am convinced that if(xx) statements should execute if the variable xx is non-zero. You don't have to make the statement if(xx != 0). Am I missing something? I'm assuming false = 0 and true = non-zero.
Thanks, all. I will work on my own debugging until I'm more frustrated than I am at the moment. Debugging is a learning process, so I like to do it up until I start looking for rope and making a 13 turn knot.
Regardless, that's not what I asked. What I asked (and was answered, with a few diversions to possible reasons the variable could be corrupt) was, is zero (0) equivalent to "false". One doesn't need to see 497 lines of code to answer that question.
If you formulate a question such that it is clear the answer is obvious to you, you will obviously get questions about why you are asking the question.
Delta_G:
Any non-zero value will evaluate as true.
Dr_Quark:
...zero (0) equivalent to "false".
These statements must be taken literally. Zero (0) is equivalent to false and any non-zero value will evaluate as true. Which is different than greater than zero. I have worked through many a learners program where the result of Valve_err (to use the example provided) turned out to be a negative number in which case was {blah blah} executed. The learner was not expecting the negative number and was also not expecting the conditional statements to execute. In some cases, the negative number should not have existed and the code was fixed elsewhere, in other cases the if statement was changed from (Valve_err) to (Valve_err>0).
if(digitalRead(somePin) == HIGH)
A few more characters adds to commenting your code.
For sure, we have all done this: #define PUSHED LOW
. . .
if(digitalRead(somePin) == PUSHED)
However there are those that like to be cryptic.
if(digitalRead(somePin))
No, it's not being cryptic. It's when you have a byte that is made up of various error flags and you want to execute a particular thing if any flag is set.
so
If(err_byte) {}
is a lot simpler than analyzing each bit in the err_byte.
I also agree with those who are concerned when
int OFF = 1 ;
int ON_ = 0 ;
digtalWrite(pinX, OFF) ;
Constructing expressions which rely on the internal representations of true, false etc. can lead to confusion and make code difficult (for someone else) to read. In not all languages does true have the value 1 and false the value 0. In visual basic, for example, true has the value -1. I guess also there are languages which prevent the use of true and false in anything other than a boolean context.
6v6gt:
In not all languages does true have the value 1 and false the value 0. In visual basic, for example, true has the value -1. I guess also there are languages which prevent the use of true and false in anything other than a boolean context.
CtrlAltElite:
If it were possible, I now respect Microsoft even less.
That is why I was very specific on my response to the OP.
adwsystems:
Zero (0) is equivalent to false and any non-zero value will evaluate as true. Which is different than greater than zero.
Since I don't often work in VB (plus I also tend to be verbose in writing the if conditions while also programming under the mantra to not do anything in a way I will have to relearn two months from now), I forgot about this SNAFU. But as you see, even though true = -1, it is still a non-zero value.
In visual basic, for example, true has the value -1.
I think that illustrates the point very well. There is no need to know what the value of true and false are as long as you always set the boolean variable to true or false and test it for true or false.