所以，我熟悉使用整数内的单个位打包一堆布尔值的概念（我认为它称为位掩码），因此您可以节省内存，因为布尔值是一个字节并且您适合一个字节长整数中的多个布尔值。因此，如果你有足够的布尔值，将它们打包在一起会产生很大的不同，我们看到在原生虚幻源代码中，这种特殊的优化被大量使用。但是，我不清楚的是，这有什么缺点？有些地方使用了许多常规布尔值。另外，为什么在某些地方使用 uint32 而在某些地方使用 unint8？我读过可能存在一些与读写相关的低效率或什么？
【问题讨论】：
标签： c++ integer boolean unreal-engine4 bitmask
最大的问题是没有指向“packed bool”的指针——就像你有一个包含 32 个布尔值的 int32 一样，那么你不能以正确的方式使 bool* 或 bool& 引用它们中的任何一个。这是因为字节是最小的内存单元。
在 STL 中，他们制作了 std::vector<bool>，既节省了空间，又在语义上与其他向量具有相同的接口。为此，他们必须创建从operator [] 返回的特殊代理类，因此可以执行boolVec[5] = true 之类的操作。不幸的是，这种过度复杂化导致了std::vector<bool> 的性能和使用方面的许多问题。
即使是压缩布尔值的简单指令也往往是复合的，因此比通过bool 表示并占用一个完整字节的布尔值更重。此外，修改压缩布尔值的值可能会导致多线程环境中的数据竞争。
基本上，硬件不太支持布尔值。
接下来，操作系统设计器的图像 POV 和您创建共享库（又名 dll）的通用接口。现在如何处理布尔值？字节是最小的内存单元，因此要传递一个布尔值仍然需要使用至少一个字节。那么为什么不简单地忘记 bool 的存在并简单地通过单个字节传递它呢？所以我们甚至不需要实现这种不必要的 bool 类型，它将为所有语言的所有编译器编写者节省大量时间。
uint8 与 uint32;另外，请注意 Windows 的 COM（组件对象模型 - 不是串行端口）使用 int16 作为布尔值。一般来说，它本质上并不重要，因为当将值传递给执行复杂操作的共享库的函数时，不会对性能产生任何明显的影响，因为您已经调用了一个更重的函数。还是为什么会这样？我想他们很久以前设计它时有一些原因，每个人都已经忘记了原因，他们只是保持不变，因为改变它会导致向后兼容性方面的彻底灾难。
在 C99 中，_Bool 是为布尔值引入的，但它只是无符号整数的不同名称。我从 uint32 的这种原始用法中想象布尔值。一般来说，int 在性能方面被认为是最有效的整数类型（这就是它的大小没有严格定义的原因）——因此 C 委员会选择了被认为最有效的类型来表示布尔值。
【讨论】：