objective-c - 不在 Objective-C 中使用 _Bool 的原因？

Question

从 C99 开始，C 现在有了一个合适的 boolean 类型，_Bool。 Objective-C 作为 C 的严格超集，继承了这一点，但是在 1980 年代创建时，没有 C boolean 类型，所以 Objective-C 将 BOOL 定义为 signed char 。

所有 Cocoa 都使用 BOOL，就像我见过的所有非 NeXT/Apple Cocoa 代码一样。显然，为了与现有协议(protocol)兼容(例如 -applicationShouldTerminateAfterLastWindowClosed: 来自 NSApplicationDelegate)，匹配已经声明的类型是更可取的，如果除了避免警告之外没有其他原因的话.

出于清洁/可读性的目的，stdbool.h 将 bool 定义为 _Bool 的同义词，因此我们这些不希望我们代码中不必要的下划线可以使用它。

其他三个有用的注释:

• @encode(_Bool) 的计算结果为 "B"。 (对于 signed char，@encode(BOOL) 的计算结果为 "c"。)
• sizeof(_Bool) 的计算结果为 1，这遵循 C99 的定义，即 _Bool 的大小仅能容纳其两个可能的值值。 (编辑: 实际上，该标准只是说它必须“足够大”以容纳这两个值；它没有设置上限，事实上，Mac OS X on 32-bit PowerPC defines it as 4 bytes. 大小差异是另一个在可能的 BOOL-vs.-bool 兼容性问题下提交的事情。)
• 关于这一点，_Bool 的唯一可能值是 1 和 0。任何其他值在赋值时都将转换为其中之一，就好像您进行了双重否定 (!!) 或针对 0 测试不等式 (!= 0)。获得具有其他值的 _Bool 的唯一方法是常用的魔法:指针别名和联合。

有什么理由不在新代码中使用 _Bool/bool 吗？

Answer 1

我想你们几乎都回答了自己的问题——不在新的 Cocoa 代码中使用 _Bool 的原因是，直到 Apple 将其框架改为使用 _Bool(或者更可能是 stdbool.h 中定义的 bool)，你通过使用 _Bool 或 bool 来打破惯例和可能的兼容性(至少没有破解)。虽然我现在才沉浸在 Cocoa 编程中几年，但我敢打赌，如果 Apple 完全合并了 _Bool，他们可能会简单地重新定义 BOOL 宏以无论如何在幕后使用新类型，以避免无法解释的编辑他们的框架及其文档。

话虽这么说，(并且让我先声明我还没有将 C 代码与 Objective-C 混合并且不知道这样做的约定)，你有一个更好的例子来使用C 函数中的 new _Bool，可能需要注意的是它仅在内部使用并且不要求 Objective-C 方法传入 _Bool，只是为了避免对 future 的程序员造成混淆。当然，您还必须对始终需要 C99 编译感到满意，人们可能仍然有理由避免这样做。考虑到 YES 是 1 的宏，NO 是 0 的宏，要求较新版本的 C 获取另一个仅使用 1 或 0 的字符大小的值似乎没有太大好处。

老实说，归根结底，您可以通过足够的黑客技术或对可重用性的限制来解决这些原因中的任何一个，但最终的理由是它(目前)不是 Cocoa/Objective-C 俚语的一部分，并且它的好处可能不会超过可读性的损失和/或增加其他不那么隐私的 _Bool 程序员阅读您的代码的困惑。