PaulS:
In Arduino.h, boolean is a typedef for uint8_t. I suspect that the bool type is optimized for holding true or false, while the boolean pseudo-type is not.
Doesn't it have to be the other way round? Because in my sketch, boolean gets a smaller output than bool.
lloyddean:
'bool' is the same size as 'int' which is 2 bytes on most Arduino boards.
But why doesn't changing the function return variable from boolean to bool the sketch compiled size then?
The size of the sketch isn't directly a result of the size of the variables. That is, increasing a variable you use from a byte to an int isn't going to increase the sketch size by a single byte. It will affect the SRAM, but the program memory is dependent on the AVR instruction set. So if changing an aspect of the code doesn't affect the sketch size, that means that either it didn't affect the assembled code, or the same overall size instructions are used.
lloyddean:
My mistake apparently it may be compiler, and, or architecture dependent.
My results match 1 byte on the current compiler as well.
Same under Windows (VS), MacOS (clang) and several version of Linux (gcc).
I wonder when that changed ...
I'm guessing bool is the "fastest" type, which is not necessarily the smallest type. On an 8 bit computer, 8 bits is the fastest. On bigger computers, the fastest size can be different.
fran83:
after googling for a while I found out that bool and boolean can be used interchangeably in the Arduino IDE. Is that correct?
Pretty much.
I personally prefer bool, because it is standard C language style. What do you think?
I prefer bool.
And if it is correct, why do I get a 14 bytes larger program when compiling the following code:
Serial.println(heatingStatus);
heatingStatus is extended to 16 bits (one machine instruction) when heatingStatus is bool (different println is called).
Serial.println(mixerStatus);
Ditto. Repeat for the remaining prints.
Another strange thing: whether or not I declare the function at line 35 as bool or boolean I always get the same compiled size.
What is wrong with the compiler?
First, even though it does work, returning 1/0 is not correct. A bool is either true or false.
You get the same size code because bool and boolean are both one byte and 1/0 is essentially interchangeable with true/false.
That is, increasing a variable you use from a byte to an int isn't going to increase the sketch size by a single byte.
Changing a "byte" (unsigned eight bit) to an "int" (signed sixteen bit) may make quite a large difference to the size of your sketch, but changing it for a more similar type, such as "unsigned int" may make no difference at all.
I know this is an old thread, but it is currently interesting to me.
I have a related question:
If I have 8 config bits, what is the most efficient way to go?
EIGHT bool seperate variables? Or...
ONE byte variable, looking at each bit individually?
In terms of memory efficiency, your last suggestion, pack the 8 bits into a byte.
You can use either a structure with a byte:bit definition or use bit manipulation directly.
The most important "efficiency" to optimise is the programmer's. If you can make the computer do work for you (like storing a bit) then let it take care of the details. This is MUCH easier if there are separate bool variables even though it takes up 8 times the storage space.
The benefit of this is not immediately apparent. When you're writing the code, it's pretty simple to come up with a system of packing CONFIG_LED_ON into the 3rd bit of your second config byte. But a month or two from now you will need to make some small change to the program - how do you find all the references to the 3rd bit and how do you even know that bit is doing that thing that you want to change?
There will come a point where your program no longer fits into the memory space of an Uno and the box it's built into can't fit a Mega, so then you go looking for places to reduce your memory usage. This is an example of "some small change" and it's sill most important that the program is understandable.
rockwallaby, vaj4088, MorganS: You are all correct.
My original question was, as all of you point out, is dependent on my personal preference. I want memory efficiency but I also want it to be easy to use. Bool's are easier to use, which is my primary consideration...until I run low on resources.
But rockwallaby is wrong about one thing: I definitely won't document "accordingly & verbosely". I would, if I thought anyone else would read my code, but I'm lazy. And usually half drunk (when I do my best work).
I've done bitwise programming in the past, and it does become difficult to track down the 3rd bit of the 2nd byte...certainly more confusing that bools, even with excellent documentation.
The truth is, I was hoping the faceless master programmers of the internet would have some secret trick that solved all my problems. I don't meet many other programmers in my profession, so I don't often get to "Talk Shop" with other people who know whats up.
btmcmahan:
I know this is an old thread, but it is currently interesting to me.
I have a related question:
If I have 8 config bits, what is the most efficient way to go?
EIGHT bool seperate variables? Or...
ONE byte variable, looking at each bit individually?
btmcmahan:
I've done bitwise programming in the past, and it does become difficult to track down the 3rd bit of the 2nd byte...certainly more confusing that bools, even with excellent documentation.
You can try my BitBool library, it may help to solve your confusion.
Basically it creates an array of bits you can access just like an array.
BitBool< 500 > bits; //Create 500 bits (63 bytes)
bits[ 120 ] = 1; //or true/false (121'st bit, zero based index like arrays)
Coding Badly: I don't understand the purpose of this code you posted, why is it better to create a structure of bools rather than just creating the bools separately? I get that it helps for organizational reasons, but does it have some other benefit?
btmcmahan:
Coding Badly: I don't understand the purpose of this code you posted, why is it better to create a structure of bools rather than just creating the bools separately?
They are packed into the fewest number of bytes. The structure in my example is packed into a single byte of SRAM. @LarryD's example is also packed into a single byte of SRAM.
The compiler automatically handles the packing. If @LarryD's example had 15 fields the compiler would pack the structure into two bytes of SRAM.
As an added bonus, the latest compiler uses bit manipulation instructions with SREG/T reducing the generated code a little.
You get the storage benefits of manipulating individual bits without all the fiddly.