在您开始大喊未定义的行为之前,这已在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]中定义
对于普通可复制类型,值表示是对象表示中确定 值 的一组位,该值是实现定义的一组值的一个离散元素。
除了提到无关紧要的并发以及使用 内存位置 而不是 标量对象 外,它们是相同的,其中
算术类型、枚举类型、指针类型、指向成员类型的指针std::nullptr_t、以及这些类型的 cv 限定版本统称为标量类型。
std::nullptr_t
这不会影响示例。
来自[N4659 expr.ass]
赋值运算符 (=) 和复合赋值运算符都从右到左分组。所有这些都需要一个可修改的左值作为它们的左操作数,并返回一个指向左操作数的左值。如果左操作数是位域,则所有情况下的结果都是位域。在所有情况下,赋值都在左右操作数的值计算之后和赋值表达式的值计算之前进行排序。右操作数在左操作数之前排序。
来自[N3337 expr.ass]
赋值运算符 (=) 和复合赋值运算符都从右到左分组。所有这些都需要一个可修改的左值作为它们的左操作数,并返回一个指向左操作数的左值。如果左操作数是位域,则所有情况下的结果都是位域。在所有情况下,赋值都在左右操作数的值计算之后和赋值表达式的值计算之前进行排序。
唯一的区别是 N3337 中没有最后一句。
然而,最后一句话不应该有任何重要性,因为左操作数i既不是 “另一个副作用” 也不是 “使用相同标量对象的值” ,因为 id 表达式 是一个左值。
i
在 C11 中,“赋值”的行为,即修改 LHS 的副作用,是在右操作数的 值计算之后排序的。 请注意,这是一个相对“弱”的保证:它只产生与RHS 的 值计算相关的排序。 它没有说明RHS 中可能存在的 副作用,因为副作用的发生不是 价值计算 的一部分。C11 的要求没有在赋值行为和 RHS 的任何副作用之间建立相对顺序。这就是为 UB 创造潜力的原因。
在这种情况下,唯一的希望是 RHS 中使用的特定运算符做出的任何额外保证。如果 RHS 使用前缀++,则特定于前缀形式的排序属性++将在本示例中节省时间。但是后缀++是另一回事:它不做这样的保证。=在 C++11 中,和 postfix的副作用++在此示例中最终彼此无序。那就是UB。
++
=
在 C++17 中,赋值运算符的规范中增加了一个额外的语句:
右操作数在左操作数之前排序。
结合上述内容,它提供了非常强大的保证。它将RHS 中发生的 所有 事情(包括任何副作用)排在LHS 中发生的 所有事情之前。 由于实际分配是在 LHS(和 RHS) 之后 排序的,因此额外的排序将分配行为与 RHS 中存在的任何副作用完全隔离开来。这种更强的排序是消除上述 UB 的原因。
(更新以考虑@John Bollinger 的评论。)