Bool vs Boolean - again

Hey guys,

after googling for a while I found out that bool and boolean can be used interchangeably in the Arduino IDE. Is that correct?
I personally prefer bool, because it is standard C language style. What do you think?

And if it is correct, why do I get a 14 bytes larger program when compiling the following code:

http://pastebin.com/t7LxjMJ7

and declaring the variables at line 20 and 21 as bool instead of boolean?

(boolean: 8378 bytes, bool: 8392 bytes).

I know, it is not that much memory, but every little byte counts when you only have 32k of them...

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?

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.

'bool' is the same size as 'int' which is 2 bytes on most Arduino boards.

because it is standard C language style.

I use unsigned char, which at comparison time, is really int.

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.

  Serial.println(sizeof(bool));
  Serial.println(sizeof(boolean));

returns
1
1

so size seems to be the same on first sight.

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

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.


Paul

The answer is: It depends.

What is YOUR definition of efficiency?

Eight separate variables will probably be faster but will use more memory.

Packing the configuration as eight bits in a byte will save memory but may incur more time involved (and more code) in packing and unpacking the bits.

What are you trying to accomplish?

1 Like

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.

MorganS wrote :

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?

Because you WILL document your program accordingly, verbosely, leaving no chance to having to guess at a later point in time :slight_smile:


Paul

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.

static struct
{
  bool running:1;
  bool digdug:1;
}
flags;

void setup() 
{
  flags.running = false;
  flags.digdug = true;
}

void loop()
{
  flags.running = ! flags.running;
  flags.digdug = ! flags.digdug;
}

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?

Have you looked at bitfield structs?

I applied a patch back in January, which changes boolean to an alias of bool.

As of 1.6.1 (1.5.6 r2) these types are the same! (bool/boolean).

Only in C code will they both be uint8_t, C++ (ide default) is bool all the way.