c - 布尔定义

Question

每当 BOOL 数据类型不容易预定义时，我曾经使用以下定义进行布尔值，

typedef unsigned char BOOL;

（由于内存使用）。

我意识到出于性能原因使用本机总线宽度可能会更好。例如，对于 32 位处理器，它可以是

typedef unsigned int BOOL;

现在，如果我仍然想为本地总线宽度定义 BOOL，64 位处理器会发生什么。

score 13 · Accepted Answer

我不会像有效宽度那样担心本机总线宽度（这是你的目标，对吧）？在几乎任何机器上，任何体面的 c 编译器都会编译unsigned int到相当有效的宽度，所以你很高兴。

score 9 · Accepted Answer

永远不要猜测性能，衡量。测量，将给出更好的明确答案 - 请记住，这可能会在每个新的编译器版本、系统升级时发生变化......

还有一天，您可能需要一个布尔数组，在这种情况下，将处理器字用作布尔值并不是最好的解决方案。

score 5 · Accepted Answer

5

为什么不在stdbool.h中使用 bool 类型？

于 2009-03-06T05:42:15.343 回答

score 4 · Accepted Answer

4

于 2009-03-06T05:37:06.590 回答

score 3 · Accepted Answer

我建议使用预处理器。

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

score 2 · Accepted Answer

至少 x86 和 ARM 能够在 32 位寄存器中加载和存储字节而不会受到任何惩罚，因此使用 char 确实没有性能影响。我不完全确定，但我敢打赌 x86-64 也有这样的说明。（当然 x86 和 x86-64 也可以直接在寄存器中处理 8 位值。）。

所以唯一关心的可能是内存布局。当然，编译器会对齐所有内容，因此大多数情况下，结构中的 char 值会被填充，除非它们彼此相邻，否则您实际上可能会节省几个字节的空间并获得更好的缓存性能。如果你有大量的 BOOL 数组并且内存是一个问题，那么无论如何你都应该打包它们。

无论如何，这不是问题。为什么不尝试运行一个双向编译的程序，看看是否对性能或内存使用有任何重大影响。如果你发现有，你可以给自己买一瓶啤酒，假装是我送的。

score 2 · Accepted Answer

2

最适合大多数平台

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

于 2009-03-06T09:24:11.660 回答

score 0 · Accepted Answer

好吧，您总是可以将 typedef 定义为long long或其他东西，但实际上我不确定这是人们出于某种原因所做的事情。（您可能还可以根据 sizeof(int*) 或类似的东西进行条件定义）。

score 0 · Accepted Answer

0

使用 char 可能比使用整数慢。

于 2009-03-06T06:10:34.357 回答

score 0 · Accepted Answer

0

stdint.h 中的int_fast8_t应该是一个不错的选择

于 2009-03-06T10:25:47.160 回答

10 回答 10