Go Down

Topic: Using int variables for true/false indication.... (Read 68 times) previous topic - next topic

daba

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

Code: [Select]
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.
Everything works with smoke. If you let it out, things stop working.

UKHeliBob

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

Code: [Select]
LED_state = !LED_state;
Why have a state variable at all ?
Code: [Select]

digitalWrite(ledPin, !digitalRead(ledPin));
Please do not send me PMs asking for help.  Post in the forum then everyone will benefit from seeing the questions and answers.

pert

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:
Code: [Select]
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:
Code: [Select]
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.

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:
https://github.com/arduino/ArduinoCore-avr/blob/1.6.23/cores/arduino/Arduino.h#L40-L41
Code: [Select]
#define HIGH 0x1
#define LOW  0x0

Is it less confusing to you now?

daba

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:
Code: [Select]
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:
Code: [Select]
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:
https://github.com/arduino/ArduinoCore-avr/blob/1.6.23/cores/arduino/Arduino.h#L40-L41
Code: [Select]
#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.
Everything works with smoke. If you let it out, things stop working.

daba

Why have a state variable at all ?
Code: [Select]

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

Code: [Select]
//********************************************************
// 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(
Everything works with smoke. If you let it out, things stop working.

Go Up