INA 260, trouble with an if statement

@frogandtoad Is this not similar to the reverse polish notation debate? I always found that sometimes RPN made sense, but other (most?) times it didn't.

IIRC, it's akin to a stack operation, push/pop

@zander

Posted by: @zander

@frogandtoad Is this not similar to the reverse polish notation debate? I always found that sometimes RPN made sense, but other (most?) times it didn't.

IIRC, it's akin to a stack operation, push/pop

 

No, but I'm a bit confused as to which one of my posts you are referring to actually?

@frogandtoad The if (TRUE == X) debate

@zander

Posted by: @zander

Posted by: @zander

@frogandtoad Is this not similar to the reverse polish notation debate? I always found that sometimes RPN made sense, but other (most?) times it didn't.

IIRC, it's akin to a stack operation, push/pop

 

No, but I'm a bit confused as to which one of my posts you are referring to actually?

Posted by: @zander

@frogandtoad The if (TRUE == X) debate

I can't recall who mentioned this already, but you really should post examples with the correct case for C++, as to not confuse any newbies, i.e:- 'true' instead of 'TRUE'.

To answer your question, no.

In C++ there are value categories, for example, and 'lvalue' or and 'rvalue' among others.  This typically meant that an lvalue would go on the left hand side of an = operator, and an rvalue on the right.  A boolean identifier is a 'literal' and not an lvalue, therefore cannot be assigned to, and that why the compiler traps it at compile time.

It's really no different than trying to assign a value to an integer literal:

100 = 5; // fail

Does that make sense?

Cheers

@frogandtoad It's been about 20 yrs since I did any serious coding but it is slowly coming back, as a person on the spectrum, I don't learn the same way as most so it does take me longer. I remember the terms lvalue and rvalue and did know that 100=5 was nonsense, but the subtleties of TRUE and true in a forum context that is talking about concepts in a free wheeling manner is somewhat lost on me. I will endeavor to be 'code correct' in the future.

NOW

I just spotted this in my generated code from the arduino cloud

#define TRUE (1==1)
#define FALSE (!TRUE)

To my way of possibly incorrect understanding this violates much of what has been said. Keep in mind the code was machine generated, I did NOT type it in.

@zander

Posted by: @zander

@frogandtoad It's been about 20 yrs since I did any serious coding but it is slowly coming back, as a person on the spectrum, I don't learn the same way as most so it does take me longer. I remember the terms lvalue and rvalue and did know that 100=5 was nonsense, but the subtleties of TRUE and true in a forum context that is talking about concepts in a free wheeling manner is somewhat lost on me. I will endeavor to be 'code correct' in the future.

NOW

I just spotted this in my generated code from the arduino cloud

#define TRUE (1==1)
#define FALSE (!TRUE)

To my way of possibly incorrect understanding this violates much of what has been said. Keep in mind the code was machine generated, I did NOT type it in.

Those 2 macros are fine, because '==' is comparing equality, and thus there is no trying to assign a literal to another, and the not or negation operator '!' is simply providing the opposite being false.

@frogandtoad I get that, but how is 1==1 different than just defining TRUE as 1, can 1==1 ever on any platform be other than 1? Isn't that syntax in street english saying 1 is equal to 1. That has to be always yes doesn't it?  Could some compier on some platform assign 0 to TRUE after evaluating 1==1?

So confused am I.

@zander

Posted by: @zander

@frogandtoad I get that, but how is 1==1 different than just defining TRUE as 1, can 1==1 ever on any platform be other than 1?

I think you're confused 🙂

The statement that '1 == 1' will always evaluate to 'true' is more correct, and portable on any platform.

Some may invent such macros for platforms that do not offer a built in boolean type.

@frogandtoad I am having trouble understanding what you are saying.

What I think you are saying is that 1==1 will always evaluate as TRUE on any platform using any compiler or interpreter. I like the concept and might use it in my own code IF what I just said is correct. I come from a background where TRUE had many representations but FALSE was always all bits off. 

I wonder why arduino puts those statements in. Do they have supported platforms that the arduino cloud runs on that define FALSE/false as something other than 0(all bits off)?

@zander

Posted by: @zander

@frogandtoad I am having trouble understanding what you are saying.

What I think you are saying is that 1==1 will always evaluate as TRUE on any platform using any compiler or interpreter. I like the concept and might use it in my own code IF what I just said is correct. I come from a background where TRUE had many representations but FALSE was always all bits off. 

I wonder why arduino puts those statements in. Do they have supported platforms that the arduino cloud runs on that define FALSE/false as something other than 0(all bits off)?

Yes.  It could be due to portability as I said, due to 'Big Endian' vs 'Little Endian' issues.

I need some sleep

@frogandtoad Ah, yes, I forgot about the endians. I am sure they (Arduino) have a VERY good reason, I am just curious enough still at 80 to want to discover their thinking as it will very likely improve my abilities. Thank you so much for your patience, I for one really appreciate it.

HI,

I stepped out of this article a little while back because I satisfied myself how the IDE compiler treats Boolean values and conditional statements involving them.

I was surprise it was still rattling around!

Anyway, I thought I would throw a peddle in the pond for you to consider, mull over.

In summary, the IDE compiler treats false/0 as false/0 in all cases. 

Conversely it treats true or any other value other than false/0 as true. 

Thus:

if x is false/0 the statement !!x evaluates to false/0, and

if x is true/!=0 the statement !!x evaluates to true/1

examples:

1. !!false evaluates to false
2. !!0 evaluates to      false
3. !!true evaluates to  true 
4. !!123 evaluates to  true
5. !!-123 evaluates to true

This simple construct supports much of the arguments put forward through these posts. 

This is the sketch that demonstrates the above:

void setup() {
  Serial.begin(9600);
}

void loop() {
  bool x;
  Serial.println("\n\nx is decared as bool...\n");
  x = false;
  Serial.print("x=false,!!x=");
  Serial.println(!!x);
  x = 0;
  Serial.print("x=0,\t!!x=");
  Serial.println(!!x);
  x = true;
  Serial.print("x=true,\t!!x=");
  Serial.println(!!x);
  x = 123;
  Serial.print("x=123,\t!!x=");
  Serial.println(!!x);
  x = -123;
  Serial.print("x=-123,\t!!x=");
  Serial.println(!!x);
  Serial.flush();
  do {} while (true);
}

Hope this lands well with you all?

Cheers

PS

are all compilers created equally?  Well that's another article altogether!!