BOOL definition

Question

Whenever BOOL datatype is not readily predefined, I used to boolean with the following definition,

typedef unsigned char BOOL;

(Owing to memory usage).

I realized it may be better to use native bus width for performance reasons. For example, for a 32 bit processor it can be

typedef unsigned int BOOL;

Now, what will happen for the 64 bit processor, if I still want to define BOOL for the native bus width.

Answer 1

I wouldn't worry about the native bus width so much as an efficient width (that was your goal, right)? On pretty much any machine, any decent c compiler will compile unsigned int to a reasonably efficient width, so you're good to go.

Answer 2

Well you could always define the typedef to long long or something, but I'm actually not sure this is something people do for some reason. (you could probably also do a conditional definition based on sizeof(int*) or something like that).

Answer 3

size_t

Answer 4

I would recommend to use preprocessor.

 #ifndef BOOL 
   #ifdef ILP32
     #define BOOL uint32_t
   #endif
   #ifdef LP64
     #define BOOL uint64_t
   #endif
 #endif

Answer 5

Why don't you use the bool type in stdbool.h?

Answer 6

Using a char might be slower than using an integer.

Answer 7

Never speculate on performances, measure. Measuring, will give the definitive answer on what is better - and remember this may change at each new compiler version, system upgrade ...

Also on day you might need an array of boolean, in which case using the processor word for a bool cannot be the best solution.

Answer 8

At least x86 and ARM are capable of loading and storing a byte to and from a 32-bit register without any penalties, so there really is no performance impact for using char. I'm not entirely sure, but I'd bet that x86-64 has such instructions too. (Of course x86 and x86-64 can handle 8-bit values directly in registers too.).

So the only concern might be about memory layout. Of course the compiler aligns everything, so most of the time, char values in structs get padded, unless they are right next to each other, then you might actually save a few bytes of space and get a slightly better cache performance. If you have huge arrays of BOOLs and memory is a concern, you should bit pack them anyway.

In any case, it's a non-issue. Why don't you try running a program compiled both ways and see, if there's any significant impact on performance or memory usage. If you find that there is, you can buy yourself a beer and pretend it's from me.

Answer 9

optimal for most platform

typedef enum { FALSE = 0, TRUE = 1, } BOOL;

Answer 10

int_fast8_t from stdint.h should be a good choice