条件评估是否优化？这段代码不好吗？答案

【问题标题】：Is condition evaluation optimized ? Is this code bad?条件评估是否优化？这段代码不好吗？
【发布时间】：2015-09-16 00:04:43
【问题描述】：

1.想象条件if (obj.is_x() || obj.is_y() || obj.is_z())
如果obj.is_x() 返回true，是否会调用obj.is_y() 和obj.is_z() 并对其进行评估？

2.这是一个坏主意（一般来说）吗？这段代码看起来很糟糕吗？

bool isbn13_prefix_valid (const string& prefix)
{
    unsigned num = stoi(prefix);
    if (num == 978 || num == 979) return 1;  //super common ones
        else if (   num >= 0 && num <= 5 || num == 7 || num >= 600 && num <= 649
                || num >= 80 && num <= 94 || num >= 950 && num <= 989
                || num >= 9900 && num <= 9989 || num >= 99900 && num <= 99999)
            return 1;
    return 0;
}

【问题讨论】：

您至少应该为这些值使用符号常量。然后，您应该考虑将每个条件重构为具有不言自明名称的单个方法。
if (num == 978 || num == 979) return 1; //super common ones else if 去掉else，是多余的。最后一个条件和num == 999一样。
容易出错，难以理解，没有直观意义，太长了。
@UweAllner：如果您想通过说明您编写的代码行数来打动您的老板，这是个好建议。如果您想完成工作，这是个坏建议。最好在规范中添加一条要求这个奇怪的值列表的评论。
完成工作是一回事；一周后能够阅读自己的代码是另一回事。我的老板不关心代码行数；他和我只对可读和可维护的代码感兴趣。一个好的编译器只是通过内联小方法来优化代码。

标签： c++ optimization conditional-statements logical-operators evaluation

【解决方案1】：

不，不会，因为short-circuiting。
是的，该代码看起来很糟糕。不是因为它不正确，而是因为您将一个极长的条件填充到单个 if 语句中。尝试重构代码以使其更简洁。

【讨论】：

【解决方案2】：

您的代码绝对没问题。我想看看这些奇怪数字来自哪里的评论，仅此而已。

按照建议将它变成十几个微不足道的函数绝对没有帮助。它实际上使阅读代码变得更加困难，因为它分散在许多代码行中。是的，这很复杂。但这是因为问题很复杂，试图将复杂性分散开来也无济于事。

您的实际问题：在 || b，首先评估a。如果为真，则不计算 b 并且结果为真。如果 a 为假，则 b 也会被评估，结果是真还是假，取决于 b 的结果。

如果优化编译器可以证明对 b 的评估没有副作用，并且它认为（主要是由于硬件中的并行性）平均而言它更快，则优化编译器可能会在它完成评估 a 之前开始评估 b尽可能多地并行评估，即使有些事情是在不必要的时候评估的。但这在您的代码结果中并不明显，只会使代码更快。

【讨论】：