I've worked through multiple Arduino books and spent a bit of time researching my question. Why do Arduino programmers use int variables for boolean operations?
My fear in posting to forums is that a question like that seems to attract answers such as "You can use boolean." Well, I know that. But why are most published examples of boolean operations using an int variable?
It's a more widespread practice than just Arduino. I'm not sure why...I don't. But then again when I started programming microcontrollers 35 years ago you scrounged for every byte of memory you could save. ints use at least 2 bytes whereas bool is 1 byte. I use the most memory efficient variables.
boolean (8 bit) - simple logical true/false, Arduino does not use single bits for bool
byte (8 bit) - unsigned number from 0-255
char (8 bit) - signed number from -128 to 127. The compiler will attempt to interpret this data type as a character in some circumstances, which may yield unexpected results
unsigned char (8 bit) - same as 'byte'; if this is what you're after, you should use 'byte' instead, for reasons of clarity
word (16 bit) - unsigned number from 0-65535
unsigned int (16 bit)- the same as 'word'. Use 'word' instead for clarity and brevity
int (16 bit) - signed number from -32768 to 32767. This is most commonly what you see used for general purpose variables in Arduino example code provided with the IDE
unsigned long (32 bit) - unsigned number from 0-4,294,967,295. The most common usage of this is to store the result of the millis() function, which returns the number of milliseconds the current code has been running
long (32 bit) - signed number from -2,147,483,648 to 2,147,483,647
float (32 bit) - signed number from -3.4028235E38 to 3.4028235E38. Floating point on the Arduino is not native; the compiler has to jump through hoops to make it work. If you can avoid it, you should.
You should always select the 'data type' best suited for your variables.
ex:
your variable does not change and it defines a pin on the Arduino. const byte limitSwitchPin = 34;
since an analog variable can be 0 to 1023, a byte will not do, you can select 'int'. ex: int temperature;
if your variable needs to be within -64 to +64 a 'char' will do nicely. ex: char joystick;
if your variable is used for ASCII then you need type 'char', ex: char myText[] = {"Raspberry Pie Smells"};
if your variable enables some code then boolean can be used. ex: boolean enableFlag = false;
millis() returns the time in ms since rebooting, ex: unsigned long currentTime = millis();
etc.
haha! Some of these Arduino books have been written by high-level college profs. I should have been suspicious of them when their examples say "if (myBool==True).....
haha! Some of these Arduino books have been written by high-level college profs. I should have been suspicious of them when their examples say "if (myBool==True).....
If the book is for beginners this is perfect acceptable. Much clearer than saying
If ( myBool ) ......
The Arduino development environment was originally intended for non-programmers. My guess is that they use 'int' instead of 'bool' just to avoid bringing up the subject of boolean expressions.
In ancient times (1970's and 1980's), C did not have a 'bool' or 'boolean' type. Many older programmers never got out of the habit of using 'int' for boolean values.
TheMemberFormerlyKnownAsAWOL:
What are "Arduino people"?
That sounded rather pejorative didn't it. I apologize. I should have said, "People who claim to know enough about Arduino to write books, post examples, maintain websites, and produce YouTube videos.....". But then, I suppose, that would be less efficient.
boolean is an arduino made up type just like byte
It's actual type varies depending on the version of the IDE. Older versions defined boolean as uint8_t later versions defined it as an actual bool.
While both are the same size, they are not the same type.
ocuser:
I've worked through multiple Arduino books and spent a bit of time researching my question. Why do Arduino programmers use int variables for boolean operations?
My fear in posting to forums is that a question like that seems to attract answers such as "You can use boolean." Well, I know that. But why are most published examples of boolean operations using an int variable?
The short and glib answer is cargo-cult programming - copying without understanding the language very well.
There's also the bleed-over from old time C programmers who code like this all the time "while (1)" being particularly obvious example as C didn't originally have a boolean type at all. This is not confined to the Arduino world (!)
There is a particular issue with digitalRead(), because conceptually it returns 1 or 0, HIGH or LOW, or a boolean value - all are natural - so what should its result type be, conceptually? int? enum? bool?
Fortunately they all work in C-style languages because of the interchangability of int types with boolean values, but I suspect this leads to confusion if you only have a partial grasp of the language, especially when boolean and logical operators like ! ~ & | && || become involved.
The barrier for publishing code is very low. Youtube, instructables, GitHub, Kindle books, personal websites. Even if you're putting out an actual dead tree book on Arduino, it's highly unlikely that the editor is a real C++ expert - they likely have a wide range of tech areas they're expected to deal with by their employers.
So there's a large number of ways that poor code can get into the wild. Arduino is particularly bad because there are a huge number of people who quite legitimately don't care about code quality - their aim is hacking something together because they want to get a project working. What they're working on may be their first and last piece of C++ for some considerable time. It's inconceivable that the standard of the code they produce will be high, but tomorrow someone will copy it from the forums and before you know it, some twenty five other projects will have reused that work.
In this situation frankly, bool versus int is the least of it. It's just merciful that Arduino sketches tend to be short so questions about design and architecture are less likely to arise.
MarkT:
There is a particular issue with digitalRead(), because conceptually it returns 1 or 0, HIGH or LOW, or a boolean value - all are natural - so what should its result type be, conceptually? int? enum? bool?
technically it is well documented as returning HIGH or LOW and that is what code should always be using.
Given the lack of specifics, code should not be assuming any particular data type nor any particular values for HIGH or LOW but yet a lot of code out there does.
Just look at all the code that got burned and wouldn't even compile under the new ArduinoCore-API since it was abusing the API by not explicitly using HIGH or LOW.
(the new ArduinoCore defined HIGH and LOW as enums)
Grumpy_Mike:
If the book is for beginners this is perfect acceptable. Much clearer than saying
If ( myBool ) ......
I think especially for beginners it is necessary to make them understand the difference between a boolean and integer. and that kinda stuff. because it make's sketches more clean and easier to understand other language's aswell.
wildbill:
The barrier for publishing code is very low. Youtube, instructables, GitHub, Kindle books, personal websites. Even if you're putting out an actual dead tree book on Arduino, it's highly unlikely that the editor is a real C++ expert - they likely have a wide range of tech areas they're expected to deal with by their employers.
So there's a large number of ways that poor code can get into the wild. Arduino is particularly bad because there are a huge number of people who quite legitimately don't care about code quality - their aim is hacking something together because they want to get a project working. What they're working on may be their first and last piece of C++ for some considerable time. It's inconceivable that the standard of the code they produce will be high, but tomorrow someone will copy it from the forums and before you know it, some twenty five other projects will have reused that work.
That's beautifully put.
I wonder what R0 for the typical Arduino sketch is...