是否存在程序员可能希望避免对布尔表达式进行短路评估的合理场景? [关闭]
Posted
技术标签:
【中文标题】是否存在程序员可能希望避免对布尔表达式进行短路评估的合理场景? [关闭]【英文标题】:is there any plausible scenario in which a programmer might wish to avoid shortcircuit evaluation of a Boolean expression? [closed] 【发布时间】:2016-09-19 13:39:36 【问题描述】:短路评估可以缩短编译时间,所以我了解到 C、C++ 正在使用这种方式。但是是否存在短路评估破坏代码的情况?
【问题讨论】:
短路评估是一种语言特性。因此,编写依赖于它不起作用的代码将无法正确表达意图。 除非任一条件是静态恒定的,否则似乎不太可能缩短编译时间。也许会缩短运行时间? '短路评估可以缩短编译时间'不,不显着。这不是使用它的原因。 更重要的是短路可以方便地写出正确的代码,比如if (p != nullptr && p->value != 25)
;如果两个操作数都被计算,这段代码会有未定义的行为。
当然,预测不佳的分支非常昂贵。因此,如果左操作数表达式是随机的,并且没有充分的理由避免评估右操作数,那么您可以明显领先。试试看,在随机文本上测量 if (ch >= 'A' && ch
【参考方案1】:
短路不会缩短代码的编译时间。 (至少任何有意义的数量)
它可能会缩短运行时间,但这不是它的预期目的。
短路的目的是做最少的工作来检查某个条件。
例如:
当使用&&
(而不是单个&
)时,如果左边的操作数为假,则不会计算右边的操作数。这是由于logical and
操作的性质:如果至少有一个操作数为假,则整个表达式为假。
从技术上讲,如果条件提前失败,它将缩短运行时间,但节省的运行时间量取决于每个操作数内的表达式。
无论如何,使用&&
是不正确的,因为它比&
“更快”。你应该在适当的时候使用。
&
用于按位运算。
【讨论】:
以上是关于是否存在程序员可能希望避免对布尔表达式进行短路评估的合理场景? [关闭]的主要内容,如果未能解决你的问题,请参考以下文章