Using int variables for true/false indication....

Projects Programming
1

I'm curious....#

I see it in many example sketches, int flag = LOW; int flag = HIGH; etc., even the Blink Without Delay example uses it. I find it slightly confusing that you can actually equate or set int's to LOW and HIGH.

Surely this is inefficient, and would it not be better to use bool variables and true/false parameters, or does the compiler reserve a byte for a bool anyway. Is there any form of compaction taking place, say multiple bools within the same byte of memory ?

I used the Blink Without Delay example, slightly modified, in my latest project, and replaced the if... else construct that toggles LED_state with the more tidy ...

LED_state = !LED_state;

There's no tests being performed to see which way you have to toggle it, it just toggles it to the opposite, achieving the same result, more efficiently, both in memory used, and speed.

I welcome any comments anyone has on these observations.

2

or does the compiler reserve a byte for a bool anyway.

Yes

LED_state = !LED_state;

Why have a state variable at all ?

digitalWrite(ledPin, !digitalRead(ledPin));
3

daba:
I see it in many example sketches, int flag = LOW; int flag = HIGH; etc., even the Blink Without Delay example uses it.

The official example sketches do use suboptimal variable types quite often. I'm not sure what the reasoning was for this. The only thing I can think is, say you have a variable like this:

byte delay = 100;

There's a good chance that an inquisitive beginner is going to play around with the value and try something like this:

byte delay = 500;

resulting in a lot of confusion. int gives more room to experiment. They'll need to learn about the properties of the various data types eventually, but it shouldn't be forced on them too early in the learning curve.

That reasoning won't apply to a variable that will only ever hold LOW or HIGH.

I would only use the bool type for true/false values. For LOW/HIGH, I would use byte. You can use bool for that if you like, but it really doesn't make sense.

daba:
I find it slightly confusing that you can actually equate or set int's to LOW and HIGH.

Here's the definition of LOW and HIGH:

#define HIGH 0x1
#define LOW  0x0

Is it less confusing to you now?

4

pert:
The official example sketches do use suboptimal variable types quite often. I'm not sure what the reasoning was for this. The only thing I can think is, say you have a variable like this:

byte delay = 100;

There's a good chance that an inquisitive beginner is going to play around with the value and try something like this:

byte delay = 500;

resulting in a lot of confusion. int gives more room to experiment. They'll need to learn about the properties of the various data types eventually, but it shouldn't be forced on them too early in the learning curve.

That reasoning won't apply to a variable that will only ever hold LOW or HIGH.

I would only use the bool type for true/false values. For LOW/HIGH, I would use byte. You can use bool for that if you like, but it really doesn't make sense.
Here's the definition of LOW and HIGH:
ArduinoCore-avr/cores/arduino/Arduino.h at 1.6.23 · arduino/ArduinoCore-avr · GitHub

#define HIGH 0x1

#define LOW  0x0



Is it less confusing to you now?

I'm not confused, I never stated I was, just curious as to why a simple true/false argument is often implemented by a data-type that can have values that don't correlate to those parameters.

For true/false in a non-bool data-type I am aware that any non-zero value is deemed to be true, and zero is false. However, I believe that a beginner programmer should be led on the path of using the right data-types straight from the start, surely he would be less confused being given good examples that are easier to follow.

5

UKHeliBob:
Why have a state variable at all ?

digitalWrite(ledPin, !digitalRead(ledPin));

Understood that Bob, but in my case I need the state variable, because I need to blink my LED whether it is ON or OFF at the start of blinking.....

//********************************************************
// LED mode
void   UpdateLED() {
  if (LED_Blink) {
    if (millis() - previousMillis >= LED_Interval) {
      previousMillis = millis();
      LED_State = !LED_State;
    }
  }
  else {
    LED_State = false;
  }
  digitalWrite(LED, (LED_ON || LED_State));
} // UpdateLED(

EDIT : Sorry I got that description wrong, what I should have said was "I want my LED_ON state to override the blinking state".

What I am doing is using the LED as an indication of reception of a wireless remote control command, AND use it as a "Battery Low" indication, hence the ||

6

One of the advantages of using bool state variables is that you don't need to qualify the arguments in "if" statements....

bool Running;

if (Running) {
  //do something
}

...is a lot clearer (at least to me), than ...

int Running;

if (Running == HIGH) {
  //do something
}
7

daba:
I'm not confused, I never stated I was

You said:

daba:
I find it slightly confusing

That is an indisputable statement that you're confused.

daba:
just curious as to why a simple true/false argument is often implemented by a data-type that can have values that don't correlate to those parameters.

It's not a true/false argument. It's a pin state. Just because HIGH is 1 and LOW is 0, doesn't mean you should equate them to true and false.

daba:
I believe that a beginner programmer should be led on the path of using the right data-types straight from the start, surely he would be less confused being given good examples that are easier to follow.

I think it's a reasonable point of view that I share for the most part. However, I dispute that bool is the "right' data type for a pin state.

daba:
One of the advantages of using bool state variables is that you don't need to qualify the arguments in "if" statements....

You can do that with any integer data type.

daba:

bool Running;

if (Running) {
 //do something
}




...is a lot clearer (at least to me), than ...

int Running;

if (Running == HIGH) {
 //do something
}

Not to me at all. If Running was actually used to store true/false data I would consider it a reasonable opinion (though the former is still less beginner-friendly). However, assuming the value of HIGH is 1 and the value of LOW is 0 is not a good idea. Nowhere does Arduino guarantee what these values will be. They simply represent pin states, not boolean states. You can probably get away with it, but it's certainly not best practices.

8

Try compiling this code for the Arduino Uno WiFi Rev2:

void setup() {
  bool pinState = digitalRead(2);
  digitalWrite(2, !pinState);
}

void loop() {}

Compilation fails:

toggle:3:28: error: cannot convert 'bool' to 'PinStatus' for argument '2' to 'void digitalWrite(pin_size_t, PinStatus)'

   digitalWrite(2, !pinState);

                            ^
9

pert:
You said:That is an indisputable statement that you're confused.
It's not a true/false argument. It's a pin state. Just because HIGH is 1 and LOW is 0, doesn't mean you should equate them to true and false.
I think it's a reasonable point of view that I share for the most part. However, I dispute that bool is the "right' data type for a pin state.
You can do that with any integer data type.
Not to me at all. If Running was actually used to store true/false data I would consider it a reasonable opinion (though the former is still less beginner-friendly). However, assuming the value of HIGH is 1 and the value of LOW is 0 is not a good idea. Nowhere does Arduino guarantee what these values will be. They simply represent pin states, not boolean states. You can probably get away with it, but it's certainly not best practices.

I was not doing a digitalRead of a pin state and trying to toggle that, I have a bool flag "LED_Blink" that says we need to blink the LED, and a bool flag that is toggled when we need to change the state of the LED after the allotted time.

Together with the LED_ON bool flag, which overrides the blink state, it allows me to use the "logical OR" ||, which is clearly stated in the reference as a "Boolean" operator.

I have never assumed that HIGH == true, or vice versa. In my last example, Running is a state that is either true or false, it can't be anything else, so using a bool data-type to store that information, in my mind, is the correct thing to do, and I believe does make the code easier to read and understand.

I work a lot with PLCs, especially Allen-Bradley, and you simply cannot attach an integer data-type to a boolean instruction like XIC or XIO, it has to be a BOOL data-type. Conversely, you cannot write a value to a boolean output, whether it is just 0 or 1.

To me, matching data-types to the functions they perform, or the data they have to hold, is natural. As a beginner in PLC coding over 35 years ago, I was forced into it. Now I'm a relative newcomer to Arduino C/C++ and find it slightly at odds that the language allows what in my mind, would be confusing to a beginner.

10

daba:
Surely this is inefficient, and would it not be better to use bool variables and true/false parameters, or does the compiler reserve a byte for a bool anyway. Is there any form of compaction taking place, say multiple bools within the same byte of memory ?

There can be. It's called 'bit field'. It's not automatic tho', you have to code for it. And there's a price exacted in speed and flash memory since the processor has more to do to deal with the bit of interest.

daba:
I work a lot with PLCs, especially Allen-Bradley

I recognize the screen name. plcs.net alumni?

11

daba:
I have never assumed that HIGH == true, or vice versa.

If you're using this code:

daba:

bool Running;

if (Running) {
  //do something
}

As a direct replacement for this code:

daba:

int Running;

if (Running == HIGH) {
  //do something
}

Then that's exactly what you're doing.

daba:
it allows me to use the "logical OR" ||, which is clearly stated in the reference as a "Boolean" operator.

You can use || with a comparison between an int and HIGH just as well:

int Running=digitalRead(2);
int temperature = readTemperature();
if(Running == HIGH || temperature > 42) {
12

dougp:
I recognize the screen name. plcs.net alumni?

Yes, dougp, the same