关于架构：使用短路评估的好处

在大多数语言中，b不会得到评估，因为a为false，因此a && b不能为true。我的问题是，在架构方面，短路会不会更慢？在管道中，您是否只是在等待获取a的结果以确定是否应评估b时停顿？改用嵌套ifs会更好吗？这甚至有帮助吗？

还有，有人知道通常所说的短路评估吗？这个问题是在我发现我的编程朋友从未听说过短路评估并且说它不常见，也没有在许多语言中发现并且在管道中效率低下之后出现的。我不确定最后一个，所以问大家！

好的，我想想一个不同的例子来说明我的朋友可能来自哪里。他认为，由于并行评估如下语句：

将使系统崩溃，没有短路的架构(因此不允许上述语句)将在处理以下语句时更快：

因为它不能并行执行(a)，所以不能并行执行(b)。在这种情况下，允许短路的语言会比不允许短路的语言慢。

我不知道那是真的。

谢谢

如果语句是(分支基本上是goto)，则短路评估以相同的方式转换为汇编语言的分支，这意味着它不会比if语句慢。

分支通常不会使管道停顿，但是处理器将猜测是否采用了分支，如果处理器错误，则必须清除自管道作出错误猜测以来发生的所有事情。

短路评估也是它的最常用名称，在大多数语言中都以某种形式出现。

老实说，我不会为此担心。测试布尔值确实非常快。仅当第二个表达式具有副作用时，短路才变得有趣/有用：

...或取决于第一次测试：

大多数语言都会对布尔表达式进行短路评估。我一直听到它被称为短路评估。

该问题中的示例是一个非常简单的示例，实际上并没有提供太多的性能优势。当表达式要计算复杂时，可以带来性能优势。

作为一个很好的例子，假设一个游戏程序具有以下内容：

在这种情况下，冲突检测比活动检查要昂贵得多。如果系统中有许多不活动的对象，则性能将得到显着提高。

我使用的一个有用的短路是这样的：

在我看来，这非常可读，并且功能很好。通常，我会尽量避免过多的嵌套，因为这会导致代码难看。

我的所有意见。

如果不停工怎么办？实际上，如果a和b都是变量，而不是带有副作用的表达式，则可以由良好的编译器并行加载它们。除了增加行数之外，使用更多ifs没有任何好处。确实，这是第二次猜测编译器是最糟糕的一种。

这称为短路评估。

我对流水线一无所知，但是短路评估是许多语言的共同特征(这也是我所知道的名称)。在C中

根据上下文，也可以称为"防护"。

我几乎以我使用过的每种语言都看到过它-大约有十几种语言。