布尔定义
每当 BOOL 数据类型不容易预定义时，我都会使用以下定义进行布尔运算：
typedef unsigned char BOOL;
（由于内存使用）。
我意识到出于性能原因，使用本机总线宽度可能更好。 例如，对于 32 位处理器，它可以是
typedef unsigned int BOOL；
现在，如果我仍然想为本机总线宽度定义 BOOL，那么 64 位处理器会发生什么情况。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
好吧，你总是可以将 typedef 定义为 long long 或其他东西，但我实际上不确定这是人们出于某种原因所做的事情。 （您可能还可以根据 sizeof(int*) 或类似的东西进行条件定义）。
Well you could always define the typedef to
long longor 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).使用字符可能比使用整数慢。
Using a char might be slower than using an integer.
stdint.h 中的 int_fast8_t 应该是一个不错的选择
int_fast8_t from stdint.h should be a good choice
我不会担心本机总线宽度，而是担心高效宽度（这是您的目标，对吧）？ 几乎在任何机器上，任何像样的 c 编译器都会将
unsigned int编译为相当有效的宽度，所以你可以开始了。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 intto a reasonably efficient width, so you're good to go.切勿猜测表现，衡量。 测量，将给出关于什么更好的明确答案 - 请记住，这可能会在每个新的编译器版本、系统升级时发生变化...
此外，有一天您可能需要一组布尔值，在这种情况下，使用布尔值的处理器字可以不是是最好的解决方案。
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 one day you might need an array of boolean, in which case using the processor word for a bool can not be the best solution.
为什么不在 stdbool.h 中使用 bool 类型？
Why don't you use the bool type in stdbool.h?
size_t
size_t
我建议使用预处理器。
I would recommend to use preprocessor.
至少 x86 和 ARM 能够在 32 位寄存器中加载和存储字节，而不会造成任何损失，因此使用 char 确实不会影响性能。 我不太确定，但我敢打赌 x86-64 也有这样的指令。 （当然，x86 和 x86-64 也可以直接在寄存器中处理 8 位值。）。
所以唯一关心的可能是内存布局。 当然，编译器会对齐所有内容，因此大多数时候，结构中的 char 值会被填充，除非它们彼此相邻，那么您实际上可能会节省几个字节的空间并获得稍微更好的缓存性能。 如果您有大量的 BOOL 数组并且内存是一个问题，那么无论如何您都应该对它们进行位打包。
无论如何，这都不是问题。 为什么不尝试运行以两种方式编译的程序，看看是否对性能或内存使用有任何重大影响。 如果你发现有的话，你可以给自己买瓶啤酒，假装是我送的。
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.
最适合大多数平台
typedef enum
{
假=0，
真 = 1，
}
布尔；
optimal for most platform
typedef enum
{
FALSE = 0,
TRUE = 1,
}
BOOL;