【问题标题】:What will i++ + i++ evaluate to in C++17?在 C++17 中 i++ + i++ 的计算结果是什么?
【发布时间】:2016-09-30 17:21:55
【问题描述】:

看起来我们正在为 C++ 准备一个全新的“面试问题”(实际上我希望不会)。

已知在 C++17 之前是未定义的行为,但从 C++17 开始它会是良好定义的吗?

由于目前似乎没有编译器可以实现这种 C++17 修改,任何人都可以解释一下,根据表达式评估规则,x 的值将在以下代码中吗?

int i = 0;
int x = i++ + i++;

Alisdair Meredith 在他的 CppCon 2016 演讲中提到了这个例子 here,但我并不完全清楚 x 的最终值是多少(尽管他的意思是它至少是 1 )。

显然,i 本身在这种情况下将在表达式末尾为 2。

【问题讨论】:

  • @LeoHeinsaar 看来我们将来必须调整我们的反应;P ...
  • @πάνταῥεῖ 我明白,不用担心。没关系。 :-)
  • 如果有人能解释一下这会有什么用就更好了。
  • 万一在面试中被问到这样的问题,我宁愿应聘者回答:“即使它在未来的某个时候变得很好定义,这样的代码仍然应该是在我们的代码库中避免”。

标签: c++ language-lawyer undefined-behavior c++17 operator-precedence


【解决方案1】:

P0145R3 (PDF) 不会更改所有表达式的计算顺序。它只影响少数运营商。并且二进制加法不在该列表中。

因此上述代码仍未定义。

【讨论】:

  • 但 Alisdair 在他的幻灯片中明确表示它是定义明确的。我怀疑这是一个疏忽,或者是吗?
  • 我确信 Alisdair 说过,但我也确信 P0145R3 不同意他的看法。 P0145 的旧版本确实确实为一般的二元运算符提供了排序,但当前版本的范围更有限。所以我会使用论文中实际写的内容,而不是幻灯片上的内容。
  • @LeoHeinsaar 查看 PDF 的第 5 部分。
  • @NathanOliver 论文的那一部分在编写时是否符合标准?也许发生了变化?如果不是,看起来 Nicol 是对的,这可能是 Alisdair 的疏忽。
  • + 没有被触动。不过,i++ << i++ 现在定义明确。
猜你喜欢
  • 2018-05-21
  • 2019-05-03
  • 2011-05-04
  • 1970-01-01
  • 1970-01-01
  • 2017-12-29
  • 1970-01-01
  • 2019-03-11
相关资源
最近更新 更多