比较BOOL和YES危险吗？

Question

我今天在源文件中发现了一条评论:

//  - no longer compare BOOL against YES (dangerous!)

在比较BOOL反对YES在Objective-C真的那么危险吗？那为什么呢？

YES运行期间可以改变的价值吗？也许NO总是0但YES可以1,2或3- 取决于运行时,编译器,您的链接框架？

Answer 1

问题是BOOL不是本机类型,而是typedef:

typedef signed char      BOOL;

#define YES             (BOOL)1
#define NO              (BOOL)0

作为char,它的值不受限于TRUE和FALSE.另一个值会发生什么？

BOOL b = 42;
if (b)
{
    // true
}
if (b != YES)
{
    // also true
}

Answer 2

你永远不应该将布尔值与任何基于C的语言中的任何东西进行比较.正确的方法是使用以下任一方法:

if (b)

要么:

if (!b)

这使您的代码更具可读性(特别是如果您使用智能命名的变量和函数,isPrime(n)或者childThreadHasFinished)并且安全.原因如下:

if (b == TRUE)

不太安全的是,实际上有大量的值b将评估为真,并且TRUE只是其中之一.

考虑以下:

#define FALSE 0
#define TRUE  1

int flag = 7;
if (flag)         printf ("number 1\n");
if (flag == TRUE) printf ("number 2\n");

如果它按预期工作,你应该打印出这两行,但你只得到第一行.这是因为7 是如果正确治疗(0是假的,其他的一切是真实的),但平等的明确的测试结果为false真的.

更新:

回应你的评论,你认为它比编码器的愚蠢更多:是的,有(但我仍然不会将编码器的愚蠢视为一个足够好的理由 - 防御性编程总是一个好主意).

我还提到了可读性,这在我的代码中所需的功能列表中相当高.

甲条件要么是对象或一个标志(包括布尔返回值)之间的比较:

if (a == b) ...
if (c > d) ...
if (strcmp (e, "Urk") == 0) ...
if (isFinished) ...
if (userPressedEsc (ch)) ...

如果你使用(我认为)令人厌恶的:

if (isFinished == TRUE) ...

你在哪里停下来:

if (isFinished == TRUE) ...
if ((isFinished == TRUE) == TRUE) ...
if (((isFinished == TRUE) == TRUE) == TRUE) ...

等等.

为了便于阅读,正确的方法是使用适当命名的标志变量.