boolean a = false, b = true;
if ( a && b ) { ... };
在大多数语言中，由于
b为false，因此a不能为true，因此不会评估a && b。我的问题是，在架构方面，短路会不会更慢？在管道中，您是否只是在等待获取a的结果以确定是否应评估b时停顿？改用嵌套ifs会更好吗？这甚至有帮助吗？另外，有人知道短路评估通常是什么吗？这个问题是在我发现我的编程 friend 从未听说过短路评估并且说它不常见，也没有在许多语言中找到并且在管道中效率低下之后出现的。我不确定最后一个，所以问大家!
好吧，我想一个不同的例子也许可以解释我的 friend 可能来自哪里。他认为，自从并行评估如下语句以来:
(a) if ( ( a != null ) && ( a.equals(b) ) ) { ... }
会使系统崩溃，没有短路的架构(因此不允许上述语句)将在处理以下语句时更快:
(b) if ( ( a == 4 ) && ( b == 5 ) )
因为如果不能并行执行(a)，那么就不能并行执行(b)。在这种情况下，允许短路的语言会比不允许短路的语言慢。
我不知道那是不是真的。
谢谢
最佳答案
bool bool 表达式完全等同于一组嵌套的ifs，因此其效率将与之相当。
如果b没有副作用，它仍然可以与a并行执行(对于任何“并行”值，包括流水线操作)。
如果b具有分支预测失败时CPU体系结构无法消除的副作用，则是的，这可能需要延迟，而如果总是对双方进行评估，则不会出现延迟。因此，如果您确实发现短路运算符(operator)正在您的代码中创建性能瓶颈，那值得一看，但不值得担心。
但是，短路可用于控制流量，以节省不必要的工作。在我使用的语言中很常见，例如Perl习惯用语:
open($filename) or die("couldn't open file");
shell 成语:
do_something || echo "that failed"
或C/C++/Java/etc习惯用法:
if ((obj != 0) && (obj->ready)) { do_something; } // not -> in Java of course.
在所有这些情况下，都需要短路，因此只有在LHS指示应进行RHS评估时，才对RHS进行评估。在这种情况下，将性能与错误的备用代码进行比较是毫无意义的!
关于architecture - 使用短路评估的好处，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/89154/