爲什麼BOOL是一個有符號的char？

有一天，用戶向我報告了一個關於應該啓用的工具欄項目被禁用的錯誤。驗證碼（簡化了您的利益）看起來像：爲什麼BOOL是一個有符號的char？

- (BOOL) validateToolbarItem: (NSToolbarItem *) toolbarItem { 

    NSArray* someArray = /* arrray from somewhere*/ 

    return [someArray count]; 
}

我花了幾分鐘的時間來意識到-count返回一個32位無符號整數，而BOOL是一個8位有符號的字符。在這種情況下，someArray中有768個元素，這意味着低8位全爲0.當返回時將int轉換爲BOOL時，即使人們期望答案，它也會解析爲NO爲YES。

我已經改變了我的代碼到return [someArray count] > 0;然而，現在我很好奇爲什麼BOOL真的是一個簽名字符。這是真的「更好」在某種程度上，然後它是一個int？

來源

2010-09-30 mbordas

由於這個原因，你會經常看到'!! [someArray count]'（幾乎和'> 0'一樣） – cobbal 2010-09-30 23:50:11

如果你再仔細考慮一下你的問題，你會發現它非常多相當於「爲什麼*任何類型*與int不一樣？」因爲答案几乎相同。更小的標量類型在那裏，因爲它們不需要int的全部範圍。 BOOL甚至不需要完整的簽名字符範圍，但沒有可用的更小類型。 – Chuck 2010-10-01 00:40:51

無論用什麼實際類型來實現布爾變量，你都不應該將布爾表達式的結果賦值給布爾變量。去檢查你的代碼爲這樣的其他可憎的。 – Sven 2010-10-01 09:28:54

它更小，這是真的。

來源

2010-09-30 23:46:08 oadams

一個明顯的答案是它比傳統的32位和64位體系結構小四倍，並且沒有任何對齊要求。

來源

2010-09-30 23:46:36

具有諷刺意味的是，在大多數編譯器/體系結構中，它會填充其他3個字節，以便可以寫入更快的32位讀取/寫入 – 2010-10-01 00:03:37

@Paul：我從來沒有在結構中看到過任何編譯器「char」你能給個例子嗎？由於連續的存儲需求，它肯定不會在陣列中實現。 – 2010-10-01 00:07:42

struct x {int a; char b; int c; }; sizeof（x）== 12.這可能是他所指的。 – 2010-10-01 00:52:34

一個布爾值需要僅單個比特（0或1），然而標準的系統處理的是字節爲最小單元。一個布爾表示爲8位的字節，比32位整數小4倍，因此是整數字節的動機。

來源

2010-09-30 23:49:33

Bools可以節省一些空間，並將值限制在0或1，這是一個較小的類型，因爲您可能會使用浮動超過一倍或超過一長的浮動。只是空間問題。

這就是爲什麼明確使用您的投射並且在布爾值的情況下，在相同類型的兩個之間進行實際邏輯比較以淨化實際布爾值而不是截斷值的原因。

來源

2010-09-30 23:59:57 M2tM

回退到更簡單的時間。

當CPU自然地處理8位類型時，BOOL類型被創建回來，很少填充到16位或32位。然而，內存稀少，將1位填充到4個字節實際上會佔用額外內存。

請注意，BOOL可能早於C++的_bool很久以前（iirc--它們可能差不多相同的年齡，當NeXT選擇Objective-C時，C++的流行度大致相同）。

來源

2010-10-01 00:40:44 bbum

給出的答案（迄今爲止）關注的是爲什麼BOOL不是一個整數。這個答案很清楚：char小於int，當Objective-C被設計回80年代時，削減幾個字節總是很好。

但是你的問題似乎也在問：「爲什麼BOOL簽名而不是簽名？」爲此，我們可以看看在那裏BOOL是Typedef的，在/usr/include/objc/objc.h：

typedef signed char  BOOL; 
// BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
// even if -funsigned-char is used.

所以這是一個答案：Objective-C的設計師不希望的typedef BOOL爲char，因爲在某些系統上，在一些編譯器（並且記住Objective-C早於ANSI C，因此C編譯器有所不同），字符被簽名，並且在一些未簽名的字符下。設計人員希望@encode(BOOL)能夠跨平臺返回一致的值，因此他們在typedef中包含了簽名。

但是這仍然引出了一個問題：爲什麼簽名而不是簽名？我沒有確切的答案。我想象的原因是他們必須選擇一個或另一個，並決定簽字。如果我不得不進一步推測，我會說這是因爲整數是默認簽名的（也就是說，如果它們不包含簽名限定符）。

來源

2010-10-01 00:47:09 mipadi

如果沒有邏輯拋出現場，那麼這不是一個合理的決定。沒有答案？這在正規科學中是不好的。隨機性不適用於設計決策。特別是在設計正式語言時。道德？不知道。但是，想知道O-C是否是一種有價值的語言似乎是合理的。 – cedbeu 2013-07-11 18:13:56

@cedbeu：什麼讓你說有*無*邏輯？關於爲什麼'BOOL'是某種類型的'char'有很多邏輯。唯一不清楚的是它爲什麼被簽名而不是簽名，在這種情況下這兩者都是相當隨意的（這意味着你必須選擇一個，但挑選哪個並不是什麼大問題）。 – mipadi 2013-07-11 19:03:58

是的。只是，我不喜歡這個主意。我會傾向於認爲，如果你必須採取一種甚至是輕微的任意決定，這意味着核心設計中存在一些缺陷。但是你是對的，這可能不是什麼大不了的事情，並且在每種語言（brrr）的某個時刻都有可能出現這樣的任意設計決定。 – cedbeu 2013-07-12 07:27:03

爲什麼BOOL是一個有符號的char？

回答

相關問題