提问人:endolith 提问时间:4/17/2021 最后编辑:endolith 更新时间:4/17/2021 访问量:174
有没有充分的理由检查与布尔斯的平等性?
Is there some good reason to check equality with bools?
问:
我修改了一些芯片制造商的示例代码,删除了一堆我认为是愚蠢的布尔比较,例如:
if(var == TRUE)
→if(var)
if(TRUE == var)
→if(var)
if(var != TRUE)
→if(!var)
if(FALSE == var)
→if(!var)
if(TRUE == var1 || TRUE == var2)
→if(var1 || var2)
if(func() != FALSE)
→if(func())
if(func() == TRUE)
→if(func())
哪里:
#define TRUE 1
#define FALSE 0
我认为这会使代码更具可读性,甚至可能允许编译器更好地优化,但编译后的代码大小增加了 118 字节。
我错过了什么吗?这些在逻辑上应该是等价的,对吧?
答:
啊,这是我头顶上的,但是:
8051 有一个以寄存器中的单个位为条件的跳转指令,并且 .如果你的编译器知道要检查哪个位,它就可以使用它。JB
JNB
或者,您可以检查累加器中的值是否为 0 或不是 0、、。但要做到这一点,您可能需要先将值放在累加器上,这可能需要清除并移动到该值,从而增加开销。JZ
JNZ
如果你的编译器不是很老派,请使用内置但不是很标准或类似的“伪类型”,你的编译器将尽可能聪明地工作(并且可能做你打算做的事情)。_Bool
评论
这不仅没有必要,而且是一个坏主意。只有与 FALSE 进行比较是安全的,因为任何非零值都是隐式的,但将这样的值进行比较可能会失败。true
TRUE
你做对了。虽然您可能需要考虑维护。如果供应商更新此代码,您可能需要重新应用所有更改。通常,按原样使用第三方代码会更简单;没有这样的代码会确认您特定的本地编码标准或风格 - 可能以摩尔的方式,而不仅仅是这样。忍受它或不使用它;当然不要复制它。
在您自己的代码中,最好使用 stdbool.h 和 和 。但是您仍然应该避免显式测试,因为它是不必要的。bool
true
false
但是,我要避免的是隐式转换。因此,例如,非空指针测试应该是而不是常见的成语。“规则”是条件表达式应显式为布尔值。在您的情况下,如果是布尔值,则无需测试是否等于真/假。相反,如果不是布尔值,则应使用布尔表达式 / 进行测试。bool
if( ptr != NULL)
if( ptr )
var
var
0 == var
0 != var
这些建议主要涉及代码质量、健壮性、清晰度和可维护性。我怀疑它会对任何合理的编译器中的代码生成产生任何影响。
下一个:不获取任何输出(预期布尔输出)
评论
TRUE
FALSE
bool
bool
if(var == TRUE) → if(var)
var
0
1
bool
int
bool
int