Notifications
Clear all

INA 260, trouble with an if statement

57 Posts
9 Users
59 Likes
3,102 Views
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@codeslinger 

Posted by: @codeslinger

@frogandtoad NEVER compare a value or experssion to true or false.  If X is a value or expression then the proper form is 

if( X ) // check if X is true

or

if( !X ) to check if X is false.

This is expecially problematic for comparisons to true.

It sometimes can be for the inexperienced programmer, for sure.

Posted by: @codeslinger

C/C++ defines any value not equal to zero as true and any equal to zero as false.

Indeed, I am quite familar with that rule.

Cheers.


   
ron bentley reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@davee

Posted by: @davee

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

If you're familiar with C++, the boolean type is an integeral type, and is also considered a constant literal, and not an 'lvalue'... you could have used this fact to your advantage to eliminate such semantic bugs.

Cheers.


   
Ron and ron bentley reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@zander

Posted by: @zander

@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.

The C++ ISO Standard drives the compiler manufacturers, and if the compilers wish to be used by big business, then they need to be certified to adhere to the ISO C++ Standard, otherwise they are non-conforming compilers, and not worth a pich of shit.

Compiler manufacturers are allowed to implement additional features, but to be a conforming acredited C++ compiler, the manufaacturer must adhere to the core C or C++ ISO language specification, otherwise they are not a valid C or C++ compiler, full stop!

There is no way that zero and be anything other than zero, and one can be anything other than 1 in a conforming compiler, not matter how many bits the O/S of the day uses.

Cheers.


   
Ron and ron bentley reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@codeslinger

Posted by: @codeslinger

@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.

Again, this is a semantic error... it's no different to:

 if("foo" == true) {
    // ...
   }

 .. that itself, doesn't implicate the rules of the if statement holding true.

Cheers.


   
Ron and ron bentley reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@zander

Posted by: @zander

@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.

 

I don't think it is razor thin at all, and many newbies trying to learn here are already confused enough as it is... it's definately worth using the correct case sensitve syntax when quoting C++ identifiers and or language specifics.

The ISO standard is what specifies how the *core* language should be implemented by compiler manufacturers - Manufacturers are free to add additional functionality, whcih can be platform specific.

Cheers.


   
ReplyQuote
ron bentley
(@ronbentley1)
Member
Joined: 2 years ago
Posts: 382
 

@frogandtoad 

What an interesting little excursion this has been!

Yes, you are correct, my own limited testing has shown this. 

I am now better aware of the way this IDE compiler treats boolean variables, so all to the good!

Cheers

Ron B

Ron Bentley
Creativity is an input to innovation and change is the output from innovation. Braden Kelley
A computer is a machine for constructing mappings from input to output. Michael Kirby
Through great input you get great output. RZA
Gauss is great but Euler rocks!!


   
Ron and frogandtoad reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@ronbentley1

Posted by: @ronbentley1

@frogandtoad 

What an interesting little excursion this has been!

Yes, you are correct, my own limited testing has shown this. 

I am now better aware of the way this IDE compiler treats boolean variables, so all to the good!

Cheers

Ron B

Thank's Ron,

Indeed, C++ is a very powerful language which I have studied for a long time, and I confess it is my favorite language of all... it does have it's quirks, but if you study it long enough, you'll find that it is a truly elegant and robust language. IMO of course 🙂

I just wish that more of the standard library features were included in the core Arduino IDE... now that would be a game changer, eh?

Cheers


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1547
 

   
Ron reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@davee 

Sorry, I'm pretty tired now it's very late here, but just before I log off... consider what I mentioned earlier about boolean being a literal, and not considered an lvalue... therefore you cannot do what you're saying in reverse... for example, as per one of your statements:

if (x = true) // here, true is implicitly converted to a 1 and assigned to x, which still makes the condition true

... because a boolean literal is not an lvalue however, you cannot do the following:

if (true = x) // This will encounter a compile time error

If you always code this way, then you'll never spend hours chasing your tail 🙂

Cheers... will check back later today/tonight/tomorrow 🙂


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1547
 

Hi @frogandtoad,

   I was only trying to be helpful.

Assuming x is of bool type:

I haven't seen any suggestion of writing (prior to your last note)   if (true == x) ... 

if "x is true", to me, feels like the 'natural' expression we use when talking, so I 'predict' many will naturally code it that way round. 

I agree if (true == x) ... should eliminate the degraded form    if (true = x)  .... getting past the compiler,

but    if (x) ...     seems much simpler and eliminates the problem at source.

 

Best wishes, Dave

 


   
Will and Ron reacted
ReplyQuote
(@codeslinger)
Member
Joined: 4 years ago
Posts: 30
 

@frogandtoad You're right.  I ran a test with th g++ compiler on my desktop and got an error message:

"error: expected primary-expression before ‘)’ token"


   
frogandtoad and Ron reacted
ReplyQuote
(@quince)
Member
Joined: 2 years ago
Posts: 40
Topic starter  

Hello , As I read through the emails back and forth I was amazed at the depth of the decision the simple error in my bracket placement sparked, I wish I understood half of it. Reading through it did shed some light,but whoever said newbies are confused enough hit the nail right on the head. 

Reading and video are OK to a point,but there is nothing like being able to ask a question of someone who knows. I would lie to thank you all for the expertise you freely share, I am sure I will have need of it again. Quince. 

 


   
Inst-Tech and Ron reacted
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 3 years ago
Posts: 6530
 

@quince I think many of us learned something.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
Inst-Tech reacted
ReplyQuote
Will
 Will
(@will)
Member
Joined: 3 years ago
Posts: 2502
 
Posted by: @zander

@quince I think many of us learned something.

Yeah, don't say anything more than you need to say 🙂

Anything seems possible when you don't know what you're talking about.


   
Inst-Tech reacted
ReplyQuote
frogandtoad
(@frogandtoad)
Member
Joined: 5 years ago
Posts: 1458
 

@davee

Posted by: @davee

Hi @frogandtoad,

   I was only trying to be helpful.

Assuming x is of bool type:

I haven't seen any suggestion of writing (prior to your last note)   if (true == x) ... 

if "x is true", to me, feels like the 'natural' expression we use when talking, so I 'predict' many will naturally code it that way round. 

I agree if (true == x) ... should eliminate the degraded form    if (true = x)  .... getting past the compiler,

but    if (x) ...     seems much simpler and eliminates the problem at source.

 

Best wishes, Dave

 

Thank's, and I appreciate all views - I wasn't angry at all if that's what you felt.

I understand where you're coming from, and I agree that it does feel more natural as you put it. I was mainly highlighting that semantic errors do occur, and that the if statement itself worked fine as long as it was used properly.

The C++ standard does offer some alternatives, such as:

    if(X not_eq n) {}

...but unfortunately I don't think they have one for equality (==).

 
Cheers.

   
DaveE reacted
ReplyQuote
Page 3 / 4