是否优化了条件评估？这段代码不好？

1.Imagine condition 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; 
}

来源

2015-06-29 user3565923

您应该至少使用这些值的符号常量。那么你应该考虑将每个条件重构为一个具有自解释名称的单一方法。 –

'if（num == 978 || num == 979）return 1; //超级普通的 else if'摆脱其他，这是多余的。最后一个条件与'num == 999'相同。 –

容易出错，难以理解，没有直观的意义，太长。 –

没有，也不会因short-circuiting。
是的，该代码看起来不好。不是因为它不正确，而是因为你将一个非常长的条件填入单个if声明中。尝试重构你的代码，使其更清洁。

来源

2015-06-29 13:37:23

你的代码是绝对好的。我希望看到这些奇怪数字来自哪里的评论，就这些。

把它变成十几个微不足道的功能是没有任何帮助的。它实际上使得阅读代码变得更加困难，因为它遍布许多许多代码行。是的，这很复杂。但是，这是由于问题很复杂，试图将复杂性分散出去并没有一点帮助。

您的实际问题： b，首先评估a。如果它是真的，那么b不被评估并且结果是真实的。如果a为假，那么b也会被评估，结果是真或假，这取决于b的结果。

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

来源

2015-06-29 14:44:01 gnasher729

是否优化了条件评估？这段代码不好？

回答

相关问题