函数参数求值顺序在c++中始终未指定，c++17亦未改变此规则；依赖该顺序会导致未定义或未指定行为，安全做法是将有副作用的表达式提前计算并保存到局部变量。
不能依赖。C++标准明确将函数参数的求值顺序定义为 unspecified（未指定），在 C++17 之前甚至完全不保证任何顺序；C++17 虽然对部分场景（如初始化列表、赋值表达式）做了收紧，但 函数调用的实参求值顺序依然未被规定 —— 编译器可自由选择从左到右、从右到左，或穿插交错地求值每个参数。
为什么编译器不固定参数求值顺序
这不是疏漏，而是设计权衡：允许编译器根据寄存器分配、指令流水线、副作用分析等做激进优化。比如把无依赖的参数提前计算，或合并公共子表达式。一旦强制顺序，就可能牺牲性能。
常见误解是把“入栈顺序”当成“求值顺序”。事实上：
- 参数压栈方向（如 x86 的从右向左）只影响栈布局，
- 而 ++i、func() 这类有副作用的表达式何时执行，标准不管。
所以即使你看到某次编译运行结果稳定（比如总是先算左边），那只是当前编译器+优化级别的巧合，不是契约。
哪些写法会因参数顺序出问题
只要两个参数中至少有一个含副作用（修改变量、抛异常、IO、new/delete），且它们访问同一对象或存在隐式依赖，就危险。
-
f(++x, x)：x被读和改未定序 → UB（C++17 前）或未指定行为 -
processWidget(std::shared_ptr<widget>(new Widget()), priority())</widget>：若priority()抛异常，new Widget()的内存就泄漏（C++17 前） -
log("a=" + to_string(a++) + ", b=" + to_string(b++))：a++和b++的执行次序不确定，日志值不可靠
C++17 改了什么？别误信“已解决”
C++17 确实新增了若干定序规则，但函数参数求值顺序不在其列。网上常误传“C++17 规定参数从左到右求值”，这是错的 —— 标准原文（[expr.call]）仍写的是 The order of evaluation of the operands is unspecified。
真正被 C++17 明确顺序的包括：
- 初始化列表：std::vector<int> v{f(), g()};</int> → f() 一定先于 g()
- 赋值表达式：a = b() = c(); → c() 先求值，再 b() = c()，最后 a = ...
- 逗号运算符：f(), g() → f() 一定先于 g()
但 h(f(), g()) 中的 f() 和 g()，仍是未指定顺序。
安全写法：用独立语句切断依赖
核心原则：让有副作用的表达式脱离参数列表，在单独语句中完成求值与保存。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
错误写法：foo(++x, x * 2);
正确写法：
int tmp = ++x; foo(tmp, tmp * 2);
更典型的资源安全场景：
auto ptr = std::make_shared<widget>(); // make_shared 原子完成 new + 构造 + 管理 processWidget(ptr, priority()); </widget>
注意：std::make_shared 比 std::shared_ptr<t>(new T)</t> 更安全，不仅因避免两次分配，更因它把对象构造和控制块创建合并在一个表达式里，天然规避了参数顺序导致的泄漏风险。
如果必须用多个带副作用的调用，就老老实实拆成多行：
int a_val = computeA(); int b_val = computeB(); int c_val = computeC(); z(a_val, b_val, c_val);
这看起来啰嗦，但它是唯一跨平台、跨编译器、跨优化级别的可靠方案。
最容易被忽略的点是：即使你没直接写 ++x，只要参数里调用了可能修改全局状态、静态变量或传入引用的函数（比如 std::cout 、<code>strtok、自定义的 increment_counter()），就同样落入陷阱 —— 副作用不只来自 ++。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
