布爾變量的最佳大小是多少？

Question

我開始相信布爾變量的最佳大小是數據的自然寬度，即在C / C ++中它是int。 因此對於現代處理器，這通常是32位。 在機器級將其聲明為一個字節，例如需要32位讀取然后是掩碼。

但是我看到iOS中的BOOL是8位。 我曾假設使用字節的人正在使用來自8位處理器的遺留問題。

我意識到這個問題取決於使用，並且在大多數情況下，語言定義的布爾值是最好的選擇，但有時您需要定義自己的，例如當您轉換來自外部源或您想要的代碼時編寫跨平台代碼。

同樣重要的是，如果要將布爾值打包到串行流中，通過串行線路（例如以太網）發送或存儲它，最好將布爾值打包在更少的位中。 但我覺得從處理器最佳尺寸打包和解包是很可能的。

所以我的問題是我認為32位處理器上布爾值的最佳大小是32位是正確的，如果是這樣，為什么iOS使用8位。

Answer 1

是的，你是對的。 使用8位的最大優點是可以很好地將更多內容打包到結構中。

當然，在這種情況下你最好使用旗幟。

然而，最大的問題是，使用C / C ++“bool”，你不一定知道它有多大。 這意味着您不能對結構（例如二進制寫入磁盤）做出假設，而不會在另一個平台上破壞它。 在這種情況下，使用已知大小的變量可能非常有用，如果要將結構轉儲到磁盤，也可以使用盡可能少的空間。

Answer 2

它取決於體系結構，但在許多32位體系結構中，8位尋址的效率不低於32位; 這樣的“獲取和屏蔽”是在硬件邏輯中執行的。

存儲空間方面的最佳尺寸當然是1位。 例如，您可以使用位字段或位掩碼在一個單詞中打包多個布爾值。 某些架構（如8051）具有位可尋址內存。 更現代的ARM Cortex-M架構采用了一種稱為位帶的技術，允許存儲器和硬件寄存器進行位尋址

Answer 3

涉及32位提取后跟硬件屏蔽的8位數量的概念大多已經過時。 實際上，從存儲器（在現代處理器上）獲取通常是一個L2高速緩存行（通常大約64-128字節）。 在這種情況下，您處理的項目基本上每個大小都涉及獲取大量數據，然后僅使用您獲取的數據的某些子集（但是，假設您的數據或多或少是連續的，可能隨后使用更多的數據）。

C ++ 嘗試 （不一定成功）為您優化這一點。 單個bool可以是從一個字節開始的任何地方，但在大多數典型的實現中，它可以是一個字節或四個字節。 （受到很多辱罵） std::vector<bool>使用一些技巧來提供（類似）類似矢量的接口，但仍然將每個bool存儲在一個位中。 在這個過程中，它失去了被視為通用序列容器的能力 - 但是當你存儲大量的bool，並且可以忍受以類似數組的方式使用它的限制時，它實際上可能很多比許多人認為的更有用。

當/如果要保留正常的容器語義並且不介意額外的存儲空間以保持它們的原始大小時，可以使用另一個容器（例如， std::deque<bool> ）。 特別是如果你只需要儲存一小部分bool ，這通常是一個更好的選擇。