Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.