是什么让 i = i 1;在 C 17 中合法吗？

Question

在您开始大喊未定义的行为之前，这已在 N4659 (C++17) 中 明确 列出

  i = i++ + 1;        // the value of i is incremented

然而在 N3337 (C++11)

   i = i++ + 1;        // the behavior is undefined

发生了什么变化？

据我所知，来自 [N4659 basic.exec]

除非另有说明，否则单个运算符的操作数和单个表达式的子表达式的求值是无序的。 […]运算符的操作数的值计算在运算符结果的值计算之前排序。如果内存位置上的副作用相对于同一内存位置上的另一个副作用或使用同一内存位置中任何对象的值的值计算是未排序的，并且它们不是潜在的并发，则行为未定义。

其中 值 在 [N4659 basic.type] 中定义

对于普通可复制类型，值表示是对象表示中确定 值 的一组位，值是实现定义的一组值的一个离散元素

来自 [N3337 basic.exec]

除非另有说明，否则单个运算符的操作数和单个表达式的子表达式的求值是无序的。 […]运算符的操作数的值计算在运算符结果的值计算之前排序。如果标量对象的副作用相对于同一标量对象的另一个副作用或使用同一标量对象的值的值计算是未排序的，则行为未定义。

同样，值在 [N3337 basic.type] 中定义

对于普通可复制类型，值表示是对象表示中确定 value 的一组位， value 是实现定义的一组值的一个离散元素。

除了提到无关紧要的并发以及使用 内存位置 而不是 标量对象 之外，它们是相同的，其中

算术类型、枚举类型、指针类型、指向成员类型的指针、 std::nullptr_t 以及这些类型的 cv 限定版本统称为标量类型。

这不会影响示例。

来自 [N4659 expr.ass]

赋值运算符 (=) 和复合赋值运算符都从右到左分组。所有这些都需要一个可修改的左值作为它们的左操作数，并返回一个指向左操作数的左值。如果左操作数是位域，则所有情况下的结果都是位域。在所有情况下，赋值都在左右操作数的值计算之后和赋值表达式的值计算之前进行排序。右操作数在左操作数之前排序。

来自 [N3337 expr.ass]

赋值运算符 (=) 和复合赋值运算符都从右到左分组。所有这些都需要一个可修改的左值作为它们的左操作数，并返回一个指向左操作数的左值。如果左操作数是位域，则所有情况下的结果都是位域。在所有情况下，赋值都在左右操作数的值计算之后和赋值表达式的值计算之前进行排序。

唯一的区别是 N3337 中没有最后一句。

然而，最后一句话不应该有任何重要性，因为左操作数 i 既不是 “另一个副作用” 也不是 “使用相同标量对象的值” ，因为 id 表达式 是左值。

原文由 Passer By 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

在 C++11 中，“赋值”行为，即修改 LHS 的副作用，是在右操作数的 值计算 之后排序的。请注意，这是一个相对“弱”的保证：它只产生与 RHS 的 值计算 相关的排序。它没有说明 RHS 中可能存在 _的副作用_，因为副作用的发生不是 价值计算 的一部分。 C++11 的要求没有在赋值行为和 RHS 的任何副作用之间建立相对顺序。这就是为 UB 创造潜力的原因。

在这种情况下，唯一的希望是 RHS 中使用的特定运算符做出的任何额外保证。如果 RHS 使用前缀 ++ ，则特定于前缀形式 ++ 的排序属性将在此示例中节省时间。但是后缀 ++ 是另一回事：它没有做出这样的保证。在 C++11 中， = 和后缀 ++ 的副作用在此示例中最终彼此无序。那就是UB。

在 C++17 中，赋值运算符的规范中增加了一个额外的语句：

右操作数在左操作数之前排序。

结合上述内容，它提供了非常强大的保证。它将 RHS 中发生的 所有 事情（包括任何副作用）排在 LHS 中发生的 所有 事情之前。由于实际分配是在 LHS（和 RHS） 之后 排序的，因此额外的排序将分配行为与 RHS 中存在的任何副作用完全隔离开来。这种更强的排序是消除上述 UB 的原因。

（更新以考虑@John Bollinger 的评论。）

原文由 AnT stands with Russia 发布，翻译遵循 CC BY-SA 3.0 许可协议