INA 260, trouble with an if statement

Posted by: @ronbentley1

@codeslinger 

I would usually declare my variable as bool(ean), so it would be 0 or 1, false or true, hence should not be an issue and if (x== trrue) , for eg, is a perfectly valid syntax and semantic. 

True, but it is redundant when "if (x)" is less typing, less compiler work, smaller, shorter and equivalent 🙂

Hi @ronbentley1 & @codeslinger,

If 'x' has been declared as a boolean, and appropriately assigned a value or 'true' or 'false', then it is valid and equivalent to write:

   if (x)  ....          or     if (x == true)  ....

The latter may appear clearer, but you will not be the first to mean to type that, but actually type

   if (x=true) ....

This will compile without complaint, as it is syntactically correct, but your program will not work as you expect.

And I can personally guarantee, it can be a *********************** of a bug to find.

The choice is yours - others may have different opinions.

Best wishes, Dave

@ronbentley1 It will depend on what trrue is. I suspect you meant the builtin TRUE. If so, it depends. IF (X) will ALWAYS work, guaranteed by the compiler.

@frogandtoad  Yes, thanks for the reminder..it was such a short example code that I just didn't think to use the code button.. But your 100% correct I will constrain myself in the future to use the proper format...

kind regards,

LouisR

@will 

Many years ago I looked at these constructs and found that the actual generated assembler was the same.

I actually use both forms, clearly depending on my mood at time of writing!

@davee Been there, got the tee and was not happy about it at all.

This is one reason I would like to find out how to see an assembler output from the compiler. When I was still gainfully employed, I often resorted to that to squeeze the last ounce of performance out of a piece of code. FYI, I was reading all the stock market ticker lines and processing in real time at Dow Jones so speed was paramount.

@ronbentley1 I saw an article a day or two ago that at least implied that may not always hold true. Modern day compilers can create frankenstein code with all the optimization tricks they use now. The discurrion I was following was what the bits looked like for a TRUE variable. Not 100% sure, but a bool might be sometimes an 8 bit, sometimes a 16 bit, I don't know if it goes higher. So if TYRUE is any vaue that is not FALSE and FALSE is by definition ALL bits off then TRUE (8 bit variant) can be anything from '00000001) to '11111111'. Since all bits on in a signed version is actually a -ve number I think you can see the problem. I doubt I can find the article again, but I will try. Hopefully others more eloquent than I can give this subject a better treatment.

@ronbentley1 Have you looked since the era of highly optimizing compilers. As a ridiculous example, a variable in something like an Interrupt service routine used nowhere else if not declared volatile will be optimized out of existence. The compiler does not want to store variables in slow global memory, it wants everything in registers.

Back in the day, it was common practice to actually specify register as part of the declaration for the most inner loops (limited number of registers).

I would really like to see the assembler but how?

@ronbentley1 if the variable being checked is already declared as a boolean, then it is already either true or false and can be evaluated as such directly in the conditional statement. if X is true, then X==true is also true and testing X or the comparison is equivalent.  But here's the thing, declaring X to be boolean does not preclude things like

X = true;

X++;

If that sneaks its way in there then if(X==true) will evaluate to false. If(X) will still work.

@codeslinger I am having trouble with that one. First I think we can agree different languages define TRUE and FALSE differently with FALSE being '00000000'b and TRUE being '11111111'b quite often but also 0 and 1 are also common. The C standard of returning 0 from a successful function call more or less means TRUE is 0 and FALSE is anything but 0 with 1, 2, 4, 8 being classic return codes like info, warn, error, severe error.

This is because of the hardware instruction that implements this. Sorry, it's been over 50 years since my IBM hardware training but I do recall that the hardware has 'special' instructions to test a 'word' of bits. The bottom line is that FALSE is based on the fairly common 'Branch if Zero' machine code instruction and the 'Branch if NonZero'

In conventional C there was no true or false, if an if statement comparison evaluated to anything other than 0 then that was the TRUE condition so FALSE was 0.

As a programmer who worked in several languages, some concurrently I always had to be acutely aware of these subtle differences. As a result we tended to be very explicit about what defined TRUE and FALSE.

Interesting rabbit hole we have fallen into but for our newish members, maybe a little bit enlightening.

All that aside for the moment, I do not understand your answer. If FALSE is 0 in this case, then if X is non zero it is TRUE in both cases given that TRUE is anyvalue other than FALSE which is all bits off.

@codeslinger 

I looked at this again and wrote a simple sketch to test out the two syntax variants:

if (x){...}else{...}

and 

if(x == true){...}else{...}

and they both produced the same results for different values of x (x declared as boolean).

So,  I found that if x is 'true' or 'false' then the logic is as one would expect.

However, if x is other than 0 or 1 (negative or positive values) then the two statements above always deliver x as true.

So, either syntax is okay, but ensure that booleans are only assigned boolean values!

@zander No, read the C or C++ language standard.  There you will discover that false (all caps is NOT the language keyword) is defined as zoro and true is defined as anything not equal to zero when logical expressions are evaluated.  The built-in values for false and true are zero and a compiler-dependent non-zero value for true. The returning of zero for success is a convention, it is NOT a standard.  Some of the functions return 0 for success, -1 for a failuer (errno then must be queried for the exact reason) and greater than zero for some other conditions as defined by the function.  For such cases, you would not want to write if(f(x)) or if(f(x) == true) as f(x) is not returning a boolean result.  All of this is in the documentation.  If the function is returning an int, you cannot treat it as a boolean value. The machine instruction has nothing to do with the evaluation of a boolean expression in C/C++. That is defined by the language standard and is agnostic to the idiosyncrasies of the hardware.  Now, it is likely that the prevalent hardware in use at the time that C was defined may have influenced how the behavior of booleans is defined but the language does not depend on the hardware behavior.

To the last point, you are correct in terms of the logical value of X.  My point is that the symbols true and false are defined to have discreet values with false being defined as zero.  The value used in an implementation for true may be anything that is not zero.  My point is that for any non-zero value of X, if(X) will take the true path for any non-zero value of X but if(X==true) will take the true path if and only if the values of X and true are equal.  Suppose true is defined as 1.  In that case if(X==true) does not take the true path unless X is equal to 1.  That is erroneous code because the standard says that the true path is to be taken in all cases in which X is not zero.  By erroneous code, I mean code that is syntactically correct and conforms to the standard but which gives a result other than what it appears to imply. This is not a compiler bug.  It is a coding error aided and abetted by the manner in which C/C++ deals with boolean values and that they are not a type distinguishable from integers.

@codeslinger I know all caps true and false are not C keywords. Yes I confused standard and convention but to me that difference is razor thin. I think the crux of the debate is that generally speaking all/most implementations of compiler define 0 as false but not false can be anything as long as it isn't 0.

@inst-tech

Posted by: @inst-tech

@frogandtoad  Yes, thanks for the reminder..it was such a short example code that I just didn't think to use the code button.. But your 100% correct I will constrain myself in the future to use the proper format...

kind regards,

LouisR

I understand, and not to worry... it is a common occurrance, so it was a generic reminder message for both you and the viewers.

Cheers

Posted by: @codeslinger

@yurkshirelad The empty condition is fine.  

[snipped rest which is not related]

I'm 100% sure that an empty condition, is in fact an syntactical error, and should never compile.