我开始相信布尔变量的最佳大小是数据的自然宽度，即在 C/C++ 中它是 int。因此，对于现代处理器，这通常是 32 位。例如，在机器级别将其声明为字节需要 32 位提取，然后是掩码。
但是我已经看到 iOS 中的 BOOL 是 8 位。我曾假设使用字节的人正在使用 8 位处理器的剩余想法。
我意识到这个问题取决于使用情况，并且在大多数情况下，语言定义的布尔值是最好的选择，但有时您需要定义自己的，例如当您转换来自外部源的代码或您想要编写跨平台代码。
同样重要的是，如果要将布尔值打包到串行流中，为了通过以太网等串行线路发送或存储，最好将布尔值打包为更少的位。但我觉得从处理器最佳尺寸打包和拆包可能是最佳选择。
所以我的问题是我认为 32 位处理器上布尔值的最佳大小是 32 位是否正确，如果是，为什么 iOS 使用 8 位。
是的，你是对的，这取决于。使用 8 位的最大优点是您可以很好地将更多内容打包到结构中。
当然，在这种情况下你最好使用标志。
不过，最大的问题是，对于 C/C++“布尔”，您不一定知道它有多大。这意味着您不能对结构进行假设（例如二进制写入磁盘），而不会在另一个平台上破坏它。在这种情况下，使用已知大小的变量可能非常有用，如果要将结构转储到磁盘，则最好使用尽可能少的空间。
它依赖于架构，但在许多 32 位架构上，8 位寻址的效率不亚于 32 位；这样的“获取和屏蔽”是在硬件逻辑中执行的。
就存储空间而言，最佳大小当然是 1 位。例如，您可以使用位域或位掩码将多个布尔值打包在一个单词中。某些体系结构（例如 8051）具有位可寻址存储器。更现代的 ARM Cortex-M 架构采用了一种称为位带的技术，它允许内存和硬件寄存器是位可寻址的
涉及 32 位取指和硬件掩码的 8 位数量的概念大多已过时。实际上，从内存中提取（在现代处理器上）通常是一个 L2 高速缓存行（通常约为 64-128 字节）。在这种情况下，基本上您处理的每种大小的项目都涉及获取大量数据，然后仅使用您获取的数据的一部分（但是，假设您的数据或多或少是连续的，随后可能会使用更多数据）。
C++尝试（不一定成功）为您优化这一点。一个个体bool可以是一个字节以上的任何位置，尽管在最典型的实现中，它是一个字节或四个字节。（备受诟病的）std::vector<bool>使用一些技巧来提供（某种）类似矢量的接口，但仍将每个接口存储bool在一个位中。在这个过程中，它失去了被视为通用序列容器的能力——但是当你存储大量布尔值并且可以忍受以类似数组的方式使用它的限制时，它实际上可能很多比许多人认为的更有用。
当/如果你想保留正常的容器语义并且不介意额外的存储空间来保持它们的原始大小，你可以使用另一个容器（例如，std::deque<bool>）来代替。特别是如果您只需要存储一小部分bools，这通常是一个更好的选择。