每当BOOL数据类型不容易预定义时，我习惯使用以下定义布尔，
typedef unsigned char BOOL;
（由于内存使用）。
我意识到出于性能原因使用本机总线宽度可能会更好。例如，对于32位处理器，它可以是
typedef unsigned int BOOL;
现在，如果我仍想为原生总线宽度定义BOOL，64位处理器会发生什么。
答案 0 :(得分：13)
我不担心本地总线宽度，而是高效宽度（这是你的目标，对吧）？在几乎任何机器上，任何体面的c编译器都会将unsigned int编译为合理有效的宽度，所以你很高兴。
答案 1 :(得分：9)
永远不要推测表演，衡量。测量，将给出更好的答案 - 并记住这可能会在每个新的编译器版本，系统升级时发生变化......
也有一天你可能需要一个布尔数组，在这种情况下使用bool的处理器字可以不是最好的解决方案。
答案 2 :(得分：5)
为什么不在stdbool.h中使用bool类型？
答案 3 :(得分：4)
答案 4 :(得分：3)
我建议使用预处理器。
#ifndef BOOL
#ifdef ILP32
#define BOOL uint32_t
#endif
#ifdef LP64
#define BOOL uint64_t
#endif
#endif
答案 5 :(得分：2)
至少x86和ARM能够在没有任何惩罚的情况下向32位寄存器加载和存储字节，因此使用char确实没有性能影响。我不完全确定，但我敢打赌x86-64也有这样的指令。 （当然x86和x86-64也可以直接在寄存器中处理8位值。）。
所以唯一的问题可能是关于内存布局。当然编译器会对齐所有内容，因此大多数情况下，结构中的char值会被填充，除非它们彼此相邻，那么实际上可能会节省几个字节的空间并获得稍微好一点的缓存性能。如果你有大量的BOOL并且内存是一个问题，那么无论如何你都应该打包它们。
无论如何，这不是问题。为什么不尝试运行双向编译的程序，看看是否对性能或内存使用有任何重大影响。如果你发现有，你可以给自己买一杯啤酒，假装它是我的。
答案 6 :(得分：2)
最适合大多数平台
typedef enum { FALSE = 0， TRUE = 1， } BOOL;
答案 7 :(得分：0)
你总是可以将typedef定义为long long或者其他东西，但我实际上并不确定这是人们出于某种原因所做的事情。 （你也可以根据sizeof（int *）或类似的东西做一个条件定义。）
答案 8 :(得分：0)
使用char可能比使用整数慢。
答案 9 :(得分：0)
int_fast8_t应该是个不错的选择