Go Down

Topic: Bool vs Boolean - again (Read 5490 times) previous topic - next topic

fran83

Dec 27, 2012, 08:20 pm Last Edit: Dec 27, 2012, 08:23 pm by fran83 Reason: 1
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?


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.

lloyddean

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

dhenry

Quote
because it is standard C language style.


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

fran83


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.


'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?

Arrch

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.

robtillaart


Code: [Select]

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


returns
1
1

so size seems to be the same on first sight.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

lloyddean

#7
Dec 28, 2012, 12:09 am Last Edit: Dec 28, 2012, 12:11 am by lloyddean Reason: 1
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 ...

WizenedEE


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.

Coding Badly

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.

Quote
I personally prefer bool, because it is standard C language style. What do you think?


I prefer bool.

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


Code: [Select]
                Serial.println(heatingStatus);

heatingStatus is extended to 16 bits (one machine instruction) when heatingStatus is bool (different println is called).

Code: [Select]
                Serial.println(mixerStatus);

Ditto.  Repeat for the remaining prints.

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

AWOL

Quote
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.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

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?

rockwallaby

#12
May 17, 2015, 02:50 am Last Edit: May 17, 2015, 02:50 am by rockwallaby
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
http://paulalting.com

vaj4088

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?

MorganS

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.
GoForSmoke: "What GShield? You never mentioned a shield."

Go Up