C++17求值顺序变更对序列点规则的影响及代码行为疑问

好问题！咱们把这个问题拆成几个部分，先理清C++17对求值顺序的调整，再分析你给出的代码行为，最后解释编译器警告的原因。

先明确几个关键概念 #

在聊具体规则前，得先区分三个容易混淆的术语：

• 未定义行为（UB）：标准完全不约束程序行为，可能崩溃、输出乱码，甚至看起来正常但暗藏风险，绝对要避免。
• 未确定行为（Unspecified）：标准允许几种合法结果，程序会产生其中一种，但具体是哪一种由编译器实现决定，不会出现完全不可预测的情况。
• Sequenced Before（序列前置）：简单说就是“操作A必须在操作B之前完成”的约束，用来避免对同一变量的无顺序修改。

C++17前后的求值顺序变化 #

在C++17之前，函数参数的求值是未排序（Unsequenced）的——多个实参的求值可以交错执行，没有任何顺序保证。这时候func(x++,x++)属于未定义行为：两个x++对x的修改没有被Sequenced Before关系隔开，完全违反了“同一全表达式内不可无顺序地两次修改同一变量”的核心规则。

C++17对求值顺序做了针对性调整，其中和函数调用相关的规则是：

函数调用中，每个实参的求值是**不确定顺序（Indeterminately Sequenced）**的——要么第一个实参完全求值完成后再处理第二个，要么反过来，但绝对不会交错执行。

这意味着，func(x++,x++)在C++17中的行为从UB变成了Unspecified：

• 要么先求值左边的x++，此时函数收到参数47和48，x最终变为49；
• 要么先求值右边的x++，此时函数收到参数48和47，x最终也变为49。

两种结果都是标准允许的，但具体是哪一种，由编译器的实现决定。

为什么编译器还会给出警告？ #

你提到clang和gcc在C2a模式下都给出了类似“未定义行为”的警告，这其实是编译器的“善意提醒”：
虽然这种写法在C17后不再是UB，但它的行为仍然不可控，不同编译器（甚至同一编译器的不同版本）可能产生不同结果，属于不良编程风格。编译器希望你避免写出这种依赖求值顺序的代码，所以即使标准已经放宽了约束，还是会发出警告。

至于你说前置自增时gcc和clang结果不同，这正好印证了Unspecified行为的特点——编译器可以选择自己的求值顺序，两种结果都是合法的，但对你的代码来说，这种不确定性显然是风险。

总结 #

• 在C++17及之后，func(x++,x++)的行为是**未确定（Unspecified）**的，不再是未定义行为；
• 虽然合法，但这种写法依赖编译器实现，极易引发意外，强烈建议避免；
• 编译器的警告是为了引导你写出更健壮的代码，即使标准已经放宽了约束。

内容的提问来源于stack exchange，提问作者NoSenseEtAl