RVO是否生效必须实测验证，不能仅凭代码表象判断；应通过日志观察构造/移动函数调用次数、对比禁用优化前后的输出差异、检查汇编中是否出现拷贝指令来确认。
怎么验证 RVO 是否真的发生了
不能靠“代码看起来能优化”就认定生效，必须实测。最直接的方式是观察拷贝/移动构造函数是否被调用——如果没被调用，且对象只构造了一次，大概率 RVO 生效了。
常用手段：
- 在类的
CopyConstructor、MoveConstructor、Constructor和Destructor里加std::cout或日志输出，运行后看打印次数 - 用
-fno-elide-constructors（GCC/Clang）或/Od+ 禁用优化（MSVC）强制关闭 RVO，对比两次输出差异 - 查看汇编：用
g++ -S生成 .s 文件，搜索是否出现对memcpy、call拷贝构造函数等指令；若完全没出现，且对象构造地址和接收变量地址一致，就是就地构造
RVO 在 C++17 后的“强制性”陷阱
C++17 起，对纯右值（prvalue）返回（如 return MyClass{}、return func()）要求 guaranteed copy elision，即编译器必须省略拷贝/移动——但这个“强制”只适用于纯右值，不适用于具名局部变量。
也就是说：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
return MyClass{};→ 编译器必须就地构造，CopyConstructor绝对不会调用 -
MyClass obj; return obj;→ 仍是 NRVO，由编译器决定是否优化，多分支return、取地址（&obj）、绑定引用都可能让优化失效 - 即使 C++17，也不要写
return std::move(obj);——这会把左值转成右值，反而阻止 NRVO，并强制调用MoveConstructor
哪些操作会悄悄破坏 RVO/NRVO
看似无害的写法，实际会让编译器放弃优化。常见干扰项：
- 函数内有多个
return语句，且返回不同变量（如if分支分别return a;和return b;） - 对要返回的局部对象取地址（
std::cout << &obj;）或绑定非常量左值引用（auto& ref = obj;） - 函数体内抛异常、含
try/catch，或调用setjmp/longjmp - 启用调试模式（
-O0）时，多数编译器默认禁用 NRVO（RVO 的强制部分仍保留）
为什么用 auto x = func(); 比 MyClass x = func(); 更安全
这是 C++17 后推荐的写法，原因很实在：
-
auto x = func();是直接初始化，明确匹配 guaranteed copy elision 的触发条件 -
MyClass x = func();是复制初始化，虽然现代编译器通常也优化，但语义上曾允许隐式转换+拷贝两步走，在极少数边界场景（如模板推导、用户自定义转换）下可能绕过 elision - 当
func()返回类型复杂（比如依赖模板参数推导），auto还能避免手动写错类型导致的意外拷贝
真正容易被忽略的是：RVO 不是“只要对象大就自动开”，它高度依赖返回表达式的值类别和函数控制流结构。哪怕你写了完美的大对象类，一个 std::move 或一个额外的 return 分支，就可能让优化彻底失效。
