以历史角度看优化 -- C历程对于函数返回值的优化先把结论放在前面如果你的代码里还有这种“为了防止拷贝用输出参数替代返回值”的习惯那么你正在错过C历史上最精彩的一次性能革命。我有一次在审查代码时看到一位同事写了个函数参数表里塞着三个引用类型的输出参数原因是“这样避免拷贝开销”。我当时就问了一句你用的是C11还是C98他愣了一下。后面我们聊了很久从RVO聊到移动语义再聊到C17的guaranteed copy elision。那次讨论让我意识到很多人每天写C却对函数返回值这个最基础的东西的演进历程几乎不了解。函数返回值看起来是个极小的点但它的演变其实是C语言哲学变化的缩影从让你手动管、你自己看着办到编译器帮你优化、你别管再到标准保证你不花一分钱、你只管写。这篇文章我就想顺着历史的线把C函数返回值优化的完整脉络讲清楚早期C是怎么返回对象的、编译器发明了哪些优化手法、C11为什么彻底改变了规则、C17又做了什么“釜底抽薪”的改动以及我们作为普通开发者应该怎么利用这些演进写出更快也更优雅的代码。1. 一切要从C语言的“值拷贝”说起1.1 早期C的返回值机制没有魔法只有memcpyC诞生之初最重要的设计目标之一就是兼容C语言让C程序员能平滑迁移。这意味着它继承了一个最基本但也最“昂贵”的东西返回值是按值传递的也就是要拷贝。在C语言里如果你写这样一个函数struct BigStruct { char data[1024]; }; struct BigStruct make_big() { struct BigStruct s; // 填充 s.data ... return s; }那这个函数在返回时发生了什么从语义上说函数内部的局部变量s会被拷贝到调用方准备好的那块内存中。如果是1024字节的结构体那就拷贝1024字节如果是更大的结构体就拷贝更多。编译器可能会用一些技巧来减少这种拷贝比如直接在调用方的栈帧上构造返回值。但在语言的抽象语义层面拷贝就是拷贝程序员必须承认这份开销的存在。早期C面临同样的问题。但区别在于C引入了类类里面可以放string、vector、map这种自管理内存的类型甚至还可以有自己的构造函数和析构函数。这下问题就变得远比C语言的memcpy复杂。想象一下一个返回std::vector的函数如果每次返回都要把整个vector内部的动态数组全部复制一份再销毁局部变量里的那份——这不仅浪费而且完全违背了C“抽象不付费”的初衷。// 早期C程序员会尽量避免这样写 std::vectorint get_data() { std::vectorint v; v.push_back(1); v.push_back(2); return v; // 这里面到底拷贝了多少次 }这段代码如果在C98时代编译绝大多数编译器确实会拷贝——局部v构造一份返回时拷贝构造一份然后局部v析构。如果vector里面有100万个元素这就是一次O(n)的无谓复制。在那个年代这不是理论问题是真实存在的性能灾难。1.2 拷贝的代价让人发明了“输出参数”既然返回值这么贵早期C程序员自然发展出了一套“规避返回值的技巧”。最典型的就是用输出参数替代返回值void get_data(std::vectorint out) { out.clear(); out.push_back(1); out.push_back(2); }这样确实避免了返回值的拷贝你直接把数据填到调用方已经准备好的vector里。函数内部通过引用操作的是调用方的对象自然不存在“返回时再拷贝一次”的问题。但这套写法的代价是什么代码变得难读、难组合。你没法写auto result foo() bar()这种流畅的表达式必须像流水账一样一行行准备“接收容器”。这也是为什么很多老一代C代码风格看起来很啰嗦。另外一个副产品是输出参数在语义上模糊了函数的意图。一个正常的函数应该是“输入进来结果出去”输出参数却让它变成了“你先把结果的地方给我占好我去填”。如果有一天这个函数要支持并发调用输出参数还得考虑线程安全问题。所以编译器厂商也很清楚这个痛点。他们开始思考一个问题能不能让“按值返回”在机器码层面不产生拷贝于是就有了我们熟悉的RVO。1.3 一个关键的语义松动编译器优化是允许的要理解后续的优化必须先搞清楚C标准里的as-if规则编译器可以对程序做任何变换只要最终的可观察行为observable behavior和标准规定的一致就行。拷贝操作算不算“可观察行为”在C98/03的时代标准没有把“拷贝了几次”定义为可观察行为。这意味着只要拷贝结果一样编译器想少拷几次甚至一次都不拷完全合法。这个规则的松动是后面所有返回值优化的法律基础。但它也埋下了一个隐患程序员没法保证自己的代码一定能被优化因为优化是“允许编译器做”而不是“要求编译器做”。同一段代码在不同编译器、不同优化级别下表现可能完全不同。这是我特别想强调的一点读C的返回值优化历史本质上就是读一部“从依赖运气到依靠标准保证”的进化史。2. 编译器悄悄做了十几年“好事”——RVO与NRVO2.1 RVO返回值优化的第一块基石RVOReturn Value Optimization即返回值优化。它的核心思想很简单既然函数要返回一个局部对象而调用方需要一个对象来接住这个返回值那为什么不直接在调用方的内存位置上构造这个局部对象呢我用生活化的方式解释一下。假设你要在客厅放一个书架调用方需要的对象有一个工匠被调函数在作坊里造书架局部对象造完后要搬回家。RVO就是工匠先到你家客厅直接在客厅里把书架造好省掉了“搬”这一步。实现上编译器会把返回值对象的内存地址作为隐藏参数传给函数struct Big { char data[1024]; }; Big make_big() { Big b; // 初始化 b return b; } int main() { Big b2 make_big(); // 这里不再拷贝 }经过RVO优化后函数签名在实际机器码层面可能长这样void make_big(Big* __result) { // 直接在 __result 指向的地方构造 Big new (__result) Big; // 初始化... }调用方那边b2的内存就是__result一切都在原地构造零拷贝。我第一次在反汇编里看到这段逻辑时说实话挺震惊的。编译器为了性能表面上完全“违背”了源代码里“先在函数内构造再拷出去”的直观语义。但这正是C的魅力你在源语言层面描述逻辑编译器在机器层面帮你干活。RVO最常见的适用场景就是返回一个局部命名对象。像这样Big make_big() { Big b; // 填充 b return b; }注意RVO并不总是能触发。所有编译器都遵循一条经验法则只能对纯右值prvalue表达式做RVO而对左值lvalue表达式只能尝试做NRVO。这里有个很微妙的区别但先记住结论return b;中的b是一个左值理论上编译器想做RVO还要看你这个左值是否满足NRVO条件。2.2 NRVO对“有名字的局部变量”的让步NRVONamed Return Value Optimization命名的返回值优化。它和RVO的区别就在于RVO针对的是return SomeClass(...)这种“无名临时对象”NRVO针对的是有名字的局部变量。Big make_big() { Big b; // 填充 b return b; // 编译器尝试NRVO }为什么要把这两种情况分开因为语义上无名临时对象是“生来就要被移动/拷贝到外面的”编译器直接在外面构造它毫无心理负担。但有名字的局部变量不同——如果函数里有分支结构可能某些路径返回这个对象某些路径返回另一个对象Big pick(bool flag) { Big b1; Big b2; if (flag) { return b1; } else { return b2; } }这种场景下编译器没法提前决定在哪个内存位置上构造哪个对象NRVO就很难触发。NRVO不是C标准强制要求的优化甚至C98标准连提都没提这两个名词它们只存在于编译器文档里。有一段时间网上流传着一句话“RVO是编译器对标准语法的善意NRVO是编译器对程序员直觉的妥协。”我觉得这句话很准确。RVO是所有主流编译器都做得非常好的而NRVO虽然所有主流编译器也都做但触发条件更严格效果也更容易被代码改动破坏。2.3 编译器做RVO的底层依据as-if规则和内存位置在C98/03时代这些优化完全是实现细节标准一个字都没提。编译器做RVO/NRVO的唯一依据就是我前面说的as-if规则只要优化后程序的可观察行为一致随便你怎么折腾。那么问题来了什么算“可观察行为”比如打印输出、操作文件、访问volatile变量、依赖系统时间等。构造/析构函数内部的普通逻辑不算。这就给编译器留下了巨大空间。一个有意思的推论是如果拷贝构造函数有副作用RVO会改变这些副作用的发生次数但标准允许这种改变。所以很多人说“拷贝构造函数不应有副作用”否则RVO会产生奇怪的结果。这条经验到今天依然成立。举个经典例子#include iostream struct X { X() { std::cout 默认构造\n; } X(const X) { std::cout 拷贝构造\n; } X(X) { std::cout 移动构造\n; } }; X make() { X x; return x; } int main() { X x make(); }在开启了优化比如-O2的现代编译器上你很可能只看到一行“默认构造”——拷贝和移动都被优化掉了。但在-O0或者某些复杂函数里你可能看到“默认构造移动构造”甚至“默认构造拷贝构造移动构造”。这中间的差异就是优化作用的体现。2.4 RVO失效的典型场景与踩坑记录RVO虽然好但它不是万能的。我自己踩过几个典型的坑分享出来供大家参考。第一个坑同一个函数有多个return路径但这些路径返回不同的局部对象。如我前面写的pick(flag)例子两个不同对象分别返回编译器没法确定在调用方内存上构造哪一个。第二个坑在返回语句中混用了条件表达式。Big make(bool flag) { Big b1; Big b2; return flag ? b1 : b2; // 同样无法RVO/NRVO }条件运算符的结果既可能是b1也可能是b2编译器无法静态确定于是只能生成拷贝/移动代码。第三个坑把局部对象作为参数传给了另一个函数。比如Big process(const Big in) { /* ... */ } Big make() { Big b; return process(b); // 返回值来自另一个函数不是局部对象本身 }这种时候返回的是process(b)的临时结果编译器对该临时结果可以做RVO但是对b本身在其中的参与会有拷贝发生NRVO通常没法延伸到跨函数边界。第四个坑其实最隐蔽如果你的拷贝构造函数不是内联的或者类过于复杂某些编译器宁可走拷贝/移动路径也不做NRVO。这主要是优化成本考量。遇到这种情况最简单的排查手段是查看汇编里有没有调用拷贝构造函数或移动构造函数的符号。注意RVO和NRVO在C17之前都是“可能发生”的优化不要依赖它们在所有编译器上必然生效。如果你的代码必须在老标准下跨平台发布返回值路径上的拷贝开销仍然是一个真实风险。3. C11的“核弹级”改变——移动语义降临3.1 为什么说移动语义是返回值优化的分水岭C11标准引入了右值引用和移动语义这是C历史上最影响深远的架构级改动之一。但很多初学者不知道的是移动语义的出现和“解决函数返回值拷贝开销”这个看似朴素的需求有着深刻的关联。在C11之前返回一个std::vector这种自管理内存的对象哪怕编译器做了RVO仍有大量场景无法消除拷贝。更致命的是即使不做RVO我们也没有一个更轻量的方式来表达“我只是想把那堆数据挪出来”。移动构造函数的加入让“返回值”有了第二张底牌就算不做RVO编译器也可以把局部对象的内部资源“偷”出来交给返回值——通过浅拷贝源对象置空的方式完成。复制100万元素的vector瞬间变成复制三个指针再加几次赋值。std::vectorint get_data() { std::vectorint v; v.push_back(1); v.push_back(2); // ... return v; // 这里优先找移动构造函数 }在C11及之后的标准里当返回语句的表达式是局部变量或临时对象时编译器会优先选择移动构造而非拷贝构造。这从根本上改变了返回值的性能格局你不再需要依赖编译器做不做RVO来保证性能移动构造本身就足够便宜。3.2 右值引用与返回值的“资源转移”移动语义的核心是右值引用T。它的意义在于让程序能区分“一个表达式是一个左值有名字、可被取地址、可以被多次使用”还是“一个右值临时对象、行将消亡、可以被掠夺资源”。在返回语句中局部变量被隐式当作右值来处理于是编译器会匹配移动构造函数struct MyString { char* data; size_t len; MyString(MyString other) noexcept : data(other.data), len(other.len) { other.data nullptr; // 源对象不再拥有资源 other.len 0; } };这里有几个很重要的细节值得展开。第一移动构造函数必须标记为noexcept。为什么因为标准库容器如std::vector在做扩容或重新分配时如果移动构造函数可能抛异常它往往会退回到拷贝构造以保证强异常安全。某些场景编译器也会因为移动构造不是noexcept而放弃move转而走拷贝路径。第二移动后源对象必须处于可析构的合法状态。它可以是“空”的、可以是“未指定但有效”的状态但绝不能是野指针或者未初始化状态。很多初学者在自定义移动构造函数时只搬资源不清源最后导致double free这是移动语义最常见的坑。第三移动构造的成本应该接近常量时间或者小量级。如果你移动一个容器还要做O(n)的复制那就失去了移动的意义。设计移动构造函数时尽量只搬几个指针、句柄、size计数。3.3 返回路径上移动构造被调用的时机C11之后返回对象时实际发生的优化层级是这样的我从最优到最基础排一下RVO/NRVO完全消除拷贝和移动直接在调用方内存上构造。零开销。移动构造如果没有RVO/NRVO但返回的是右值或隐式转移的局部对象则调用移动构造。开销通常是O(1)级别的指针搬运。拷贝构造如果既没有RVO也没法移动比如源对象是左值且没有移动构造函数或者类不可移动只能拷贝。开销可能很大。有了这个层次图你就会明白返回值优化史上的“第一次伟大胜利”是让编译器学会了不拷贝而移动语义的伟大之处在于即使无法做到“完全不拷贝”也能做到“几乎不拷贝”。考虑一个真实的例子。老式代码往往这样写// C98 style用输出参数避免返回值开销 void merge_data(const std::vectorint a, const std::vectorint b, std::vectorint result) { result.clear(); result.insert(result.end(), a.begin(), a.end()); result.insert(result.end(), b.begin(), b.end()); }C11之后完全可以写成// C11 style直接返回值让移动构造来处理资源转移 std::vectorint merge_data(const std::vectorint a, const std::vectorint b) { std::vectorint result; result.reserve(a.size() b.size()); result.insert(result.end(), a.begin(), a.end()); result.insert(result.end(), b.begin(), b.end()); return result; }这种写法不仅读起来像“纯函数”还能组合、能推断、能放入lambda表达式、能直接作为表达式的一部分使用。同时性能消耗几乎为零——现代编译器通常会对return result;应用NRVO即使没应用也会走移动构造。3.4 return std::move(x)是优化吗——一个流传已久的迷思在C11刚发布那几年我见过太多人写这样的代码SomeClass foo() { SomeClass x; return std::move(x); // 很多人以为这是“优化” }这是一个经典的误区。我要拉出来单独讲因为它至今还在误导新手。在绝大多数情况下return std::move(x);是负优化而不是优化。原因在于std::move(x)把x变成了一个右值引用导致编译器不再对x应用NRVO。NRVO的意图是“连移动构造都省略”而std::move(x)反而强制触发了移动构造——从“可能零成本”降级成了“一定有一次移动”。用我自己踩坑的经历来说我曾经在一个性能敏感的项目里写过return std::move(local);结果用perf一测发现果真有移动构造的开销虽然移动很便宜但在这个被调用几十万次的函数里白白多出来的几万次指针搬运积少成多还是被同事吐槽了。正确的写法就是朴素地返回局部变量本身SomeClass foo() { SomeClass x; return x; // 编译器可以NRVO也可以移动。 }编译器会自己选择最优路径你不需要手动把局部变量“转成右值”。注意唯一的例外是当你返回的不是局部变量而是一个非局部对象或函数的成员时用std::move可能有意义。比如struct Wrapper { SomeClass data; SomeClass take() { return std::move(data); // 把成员“搬走”这确实是移动 } };这种情况下如果不加std::movedata是一个非局部左值编译器只能拷贝而不会自动移动。4. C17从“允许优化”到“保证不拷贝”4.1 复制省略copy elision从灰色地带变成硬性要求如果说C11用移动语义给了程序员一颗“廉价拷贝”的糖果那么C17则直接宣布在某些场景下拷贝/移动操作根本不存在——不是被优化掉了而是语言的语义层面就定义成不拷贝。这就是“保证性复制省略”guaranteed copy elision。C17标准对纯右值prvalue重定义了语义一个prvalue不是一个对象它只是初始化对象的一个“处方”。当这个处方被用来初始化一个对象时它会直接在那个对象的位置上被“求值”而不会先创建一个中间体对象再拷贝过去。用一句话概括就是return SomeClass(...);这条语句的返回值从一开始就是在调用方的存储位置上直接构造的中间没有“临时对象”这个实体。Big make_big() { return Big(/* 参数 */); // C17: 保证不拷贝、不移动 } int main() { Big b make_big(); // 保证直接在b的内存位置上构造 }这个保证不是“编译器可以优化”而是“语言规定如此”。哪怕你在编译时关闭所有优化甚至用-O0——这段代码依然不会有拷贝或移动构造的调用。这是语义级的变化不是优化级别的变化。4.2 对“临时对象”概念的重新定义理解C17的复制省略关键在于理解prvalue语义的变化。在此之前人们普遍把“表达式求值”理解为“产生一个对象”。但C17告诉你对于prvalue求值的结果是一个“初始化器”只有用它“具化”初始化某个对象的时候这个对象才存在。打个比方吧。以前的理解是“工厂生产出一个书架然后工人把书架搬到客厅”C17的理解是“工厂派人到客厅在你指定的位置上直接组装书架”。书架的诞生和放置是同一件事。这个变化带来的实际好处是你再也不用关心“临时对象会不会带来额外开销”这种问题。只要表达式是prvalue并且你把它用来初始化一个对象就不可能有额外的copy/move被调用。举个实际影响非常深远的例子struct Big { Big(); Big(const Big) delete; // 不可拷贝 Big(Big) delete; // 不可移动 }; Big make_big() { return Big(); // C17之前编译错误因为需要拷贝/移动 // C17之后合法因为根本不需要拷贝/移动 }没错在C17下你甚至可以让一个不可拷贝也不可移动的类作为函数返回值。这在C11/14时代是完全不可想象的。这就给RAII类型的工厂函数、资源管理函数的编写带来了极大的自由度。4.3 实践影响Modern C的写法可以更“放肆”C17的强制复制省略让我在写代码时心态发生了微妙的变化。以前我写返回heavy对象比如大型容器、锁、RAII句柄的函数时脑海中总会多一层顾虑这个局部变量是不是太容易被RVO了要不要用输出参数要不要用一个cache对象复用内存而现在只要函数里是return Something(...);这种写法我就心安理得——语言保证了零拷贝我不用再和编译器“猜心思”。更舒服的是配合结构化绑定和if-with-initializer等新特性代码读起来完全是声明式的class DataManager { public: // 即使底层数据很大这个返回也是零开销的 static std::shared_ptrDataManager load(std::string_view path) { auto result std::make_sharedDataManager(); // 填充数据 return result; // C17会让移动最优化而且RVO也经常生效 } }; // 调用方 if (auto mgr DataManager::load(/etc/config)) { // 使用 mgr }当然C17的guaranteed copy elision并不是覆盖所有场景的。它只保证“纯右值作为返回值”这种情形对NRVO返回具名局部变量并没有从语言层面强制NRVO依然是“允许的优化”。换句话说return local_var;的NRVO仍然是编译器的善举不是语言义务。不过因为移动语义的存在即使NRVO没触发走移动构造的开销也可控。4.4 一个容易被忽视的细节复制省略与结构化绑定的互动C17里还有一个让我印象深刻的细节就是括号初始化列表和返回值之间的关系。比如std::tupleint, double foo() { return {42, 3.14}; // 这种写法也是prvalue同样有复制省略保障 }这种花括号返回在C17下同样享有“零拷贝保证”。但要注意如果你用auto [a, b] foo();去结构化绑定a和b相当于从返回的tuple对象里“解构”出来的引用对象本身的生命周期会被自动延长或管理好。这些细节我在实际工作中踩过不少坑尤其是有一次用了一个较老的编译器gcc 6不完全支持C17的保证性复制省略结果发现返回不可移动对象时还是编译报错。这提醒我语言标准保证归保证工具链的支持程度同样重要。在生产环境里升级编译器时返回值语义的变化也是需要回归测试的重点范围。5. 从返回“对象”到返回“视图”——新需求和新的返回值形态5.1 std::string_view、std::span和“视图”式的返回值到了C20/C23函数返回值的讨论又往前推进了一步很多场景下我们返回的根本不应该是一个拥有资源的对象而是一个观察别人资源的视图。比如std::string_view它本身不拥有字符串数据只是保存了一个指针和一个长度。返回它拷贝成本几乎为零而且不涉及深层资源转移。std::string_view get_prefix(std::string_view s) { return s.substr(0, s.find(:)); }这里s是外部的字符串函数返回的是指向那片数据的“视图”。这种返回值形态彻底避开了“管理资源”的问题——因为压根不管理。但这里衍生出一个非常常见的生命周期陷阱如果把视图返回出去了而底层的拥有者已经销毁了那你的string_view就是一个悬挂指针。我自己在写解析器时犯过这类错。当时一个分词函数返回了std::string_view指向的却是函数内部局部std::string的缓冲区。函数一退出局部字符串被销毁返回出去的view就成了“幽灵”。调试了很久最后用ASan跑了一遍单测才定位到是返回了指向局部对象的视图。注意视图返回值的安全前提是“被观察对象的生命周期至少和视图一样长”。在设计接口时如果无法保证这一点建议返回std::string拥有资源或者干脆返回std::string_view并明确文档注释生命周期约束。5.2 std::optional和“可能没有返回值”的语义除了视图另一个改变返回值写法的重要设施是std::optionalT。它表达的是一个值“可能存在可能不存在”的语义——比“用哨兵值表示无”或“用布尔参数输出参数”都清晰得多。std::optionalThing find_thing(std::string_view key) { // 假设有一个 map 在别处维护 auto it lookup.find(key.data()); if (it lookup.end()) { return std::nullopt; // 明确表示“没找到” } return it-second; // 返回拷贝移动还是RVO }在C17中std::optional的构造过程同样受复制省略的保障。特别是return std::nullopt;这种分支开销极低而return it-second;如果Thing很大可能还需要一份拷贝或移动。这里就涉及可拷贝性和移动性的权衡了。很多人刚开始不太习惯optional觉得用一个特殊的“空值”不就行了但我的亲身体会是optional最大的价值不是性能而是类型安全。它把“这个函数可能没有结果”写进了类型系统里调用方想视而不见都难——你总要处理那个optional对象判断它有没有值。这样代码分支遗漏的概率大大降低。5.3 协程返回值逻辑的“异次元”C20引入了协程这对“函数返回值”来说是一次全新的挑战。协程的返回值不是直接构造在调用方内存里而是通过一个承诺对象promise type管理异步流程的产出。我理解协程返回值有三层逻辑协程启动时先构造一个promise对象它控制何时挂起、何时恢复。协程通过co_return expr;将某个值传递给promise再由promise生成调用方拿到的最终对象。返回的可能是std::futureT、生成器、任务对象等等。在这个模型里co_return expr;本身也享有移动语义和复制省略的某些好处。当expr是个prvalue时C17的保证性复制省略也能减少一层拷贝。但协程的返回值模型比我前面讨论的普通函数更为复杂优秀协程库通常会专门设计生成器对象把资源管理落入承诺对象的掌控。关于协程我不准备展开太多因为函数返回值这个话题本身已经足够广阔。但我想提一个大方向随着C20和C23逐渐普及程序员正在从“怎么高效返回一个大对象”转向“怎么描述数据流向和生命周期依赖”。视图、optional、协程生成器这些都是对“返回值”这个概念形态的延伸。理解透彻普通函数的返回值优化是读懂这些高级抽象的前提。6. 这么多年踩坑总结实践中最需要记住的几件事6.1 编译器优化与人类表达哪个优先答案是“人类表达优先”回头看这几十年的演进无数工程师花了很多精力去研究“怎么写返回值才能让编译器优化到位”。但C17之后答案变得简单优先写清晰、自然、表达意图的代码编译器会帮你把边缘的开销处理掉。具体来说我在实际项目里采用的返回值风格已经固定为几点直接用表达式返回临时对象用return SomeClass(args...);替代auto tmp SomeClass(args...); return tmp;。如果必须在函数里有多个分支返回局部对象就自然地return local_a;、return local_b;不要动脑子去“帮编译器做决定”。绝不写return std::move(local_var);除非那个local_var是成员或外部对象。如果需要“复用内存以降低多次调用的分配开销”优先考虑在调用方传一个参数进去显式in-out参数而不是依赖返回值优化。最后一条我想多说两句。返回值优化解决的是“单次调用的临时开销”但如果你在循环里反复调用一个函数每次都让它在内部构造一个大vector再return即使有RVO/移动语义vector内部的堆分配还是每次都会发生。有些场景下真的需要复用底层缓冲区。这时候用输出参数不是“退步”而是更诚实地表达“我要复用这块内存”的意图。void parse_to_buf(std::string_view input, std::vectorint out_buf) { out_buf.clear(); // 填充 out_buf }在一个10万次轮回的分析循环里这个设计比反复return一个新vector省下了大量malloc/free。6.2 怎么验证你的返回值优化真的生效了理论说再多不如看一眼真相。我推荐三种验证方式第一种写一个带计数器的小类在构造函数、拷贝构造、移动构造、析构函数里打印或累加计数。然后写一个返回该对象的函数在main里调用一次观察输出。这是我做过最直观的实验特别适合培训新手。struct Loud { static inline int copies 0; Loud() {} Loud(const Loud) { copies; } Loud(Loud) { copies; } }; Loud make() { Loud x; return x; } int main() { Loud a make(); std::cout Loud::copies \n; // 如果打印0完美打印1说明只有一个移动。 }第二种用编译器的优化报告选项。GCC用-fopt-infoClang用-Rpasscopy-elision。这些选项能直接告诉你哪些地方的拷贝/移动被省略了。比如Clang可以这样clang -stdc17 -O2 -Rpasscopy-elision test.cpp输出通常长这样test.cpp:8:5: remark: 8:5: return value elided [-Rpasscopy-elision]看到这个心里就有底了。第三种查看汇编代码。找到返回函数的ret指令附近看有没有call到拷贝构造函数或移动构造函数的指令。更粗暴一点直接搜索符号表里有没有memcpy、memmove或类的拷贝构造符号被调用。6.3 面向新标准的建议把标准版本当作优化杠杆版本号在C里不是摆设而是性能预算的一部分。我见过不少项目还在以C14为标准这意味着它们享受不到C17的guaranteed copy elision。也见过一些项目升到C20却不敢用std::span因为怕团队成员不熟练最后错过一大批语义清晰且零拷贝的方案。我个人的建议是如果还在用C11/14尽快评估升级到C17。这不仅是为了返回值优化更因为std::optional、结构化绑定、if constexpr、折叠表达式这些特性会把代码的可读性提升一个台阶。如果项目允许C20/23尽量多用std::span、std::string_view、协程库如cppcoro或标准库的生成器方向并牢记生命周期职责。无论如何升级都要建立回归性能测试尤其是在修改“返回大数据对象”的函数时把右值构造、移动路径、复制省略这几个关键数据记录下来。最后还想分享一个我珍藏已久的“小经验”在写模板库或泛型代码时返回一个auto推导的对象比显式写出类型更安全。因为auto的推导规则天然适配prvalue和移动语义不会因为中间多了一次显式类型转换而破坏复制省略的机会。template typename T auto make_default() { return T{}; // C17完美适配保证性复制省略 }这种写法在泛型场景里非常省心。你不需要关心T的拷贝水平如何也不需要关心它是否可移动——只要它能默认构造就能安全高效地被返回。7. 回到实践一条清晰的路C关于函数返回值的优化从早期“拷回来再说”到编译器私底下做RVO到C11主动用移动语义降低拷贝代价再到C17直接让prvalue不再产生临时对象——这就是一部“从依赖编译器善意到语言层语义强制”的历史。理解这条路线比单纯记住某几条编译优化规则要管用得多。我自己的体会是写代码时不要先想着“怎么让编译器把拷贝优化掉”而是先问自己这个函数返回的东西数据主权到底属于谁如果属于新对象那就老老实实return让标准替你干掉多余的开销如果属于外部既有资源那就返回视图/引用如果调用方要复用缓冲区那就显式传in-out参数。想清楚数据归属和生命周期返回值写法自然就清晰了性能也不会差。一些项目里偏爱用“返回大对象性能差”来劝阻新代码使用值返回这在C98时代或许有理但放到C17以后这个说法已经彻底过时。真正的新手恰恰应该从“大胆返回值、依赖编译器与标准帮你擦屁股”开始写起再慢慢学会在复用频繁的热点路径上做出手工权衡。所以如果你还在纠结“函数返回值要不要优化”我的建议就一句话先把标准升到你能升到的最新版本然后把你代码里所有别扭的in-out参数改回清晰的return再用编译选项或计数器验证一下。你会发现代码好写了性能也未必变差——甚至更好。这就是C历程给你带来的时代红利。