函数返回值这件事放在今天写起来好像没什么好聊的但如果你把时间轴拉长从C98一路走到C17再看到现在会发现这一条线几乎就是C对“性能”理解演变的缩影。很多老程序员应该还记得那些为了省一次拷贝而写出的“别扭”代码——输出参数、裸指针返回、手工管理的缓冲区……而如今现代C里写一个return makeObject();几乎是零成本的。这篇文章我想从历史的角度把这条线完整梳理一遍讲清楚C98时代返回值的代价到底有多大C11的移动语义为什么是一次革命C17的强制复制省略又改变了什么游戏规则以及我们今天写代码时到底该怎么选。这个问题不分水平高低初学者可以从这里建立对函数返回值的正确直觉老手可以补上一些历史细节和标准演进背后的动机哪怕你只是准备面试把这条“C返回值优化”的脉络理顺了也是一个很完整的知识框架。1. C98的尴尬一次返回就是一场拷贝灾难1.1 从一次真实代码看“拷贝”的代价如果你没有经历过C98时代你很难理解为什么老工程师们在写函数返回值时会那么“抠”。我们先看一段非常普通的代码std::vectorint makeVec() { std::vectorint v(1000000, 42); return v; } int main() { auto data makeVec(); }这段代码在今天的C17标准下编译运行data拿到结果几乎没有任何额外开销。但在C98标准下会发生什么makeVec()内部先构造出一个v这个v已经在堆上分配了100万个int的空间。然后函数返回时会调用拷贝构造函数生成一个临时对象——这意味着一百万个int被“复印”了一遍。接下来main里的data又要用那个临时对象再拷贝构造一次又是一百万个int的复制。也就是说一次看似简单的返回底层进行了三次内存分配和三次满数据的拷贝。用生活里的例子类比这就好像你去复印店复印一份100万行的文件本来你想直接把原文件带回家结果流程强制你要先复印一份放在店里再复印一份带回家里——三次复印两份都是多余的。更糟糕的是拷贝构造函数可能还会失败。比如vector的拷贝需要分配内存如果内存不足会抛出std::bad_alloc这个异常可能在函数返回的瞬间抛出导致整个调用链变得难以分析。C98时代每次写这种返回对象的函数我心里都会咯噔一下这地方是不是会成为性能瓶颈1.2 程序员的无奈反抗输出参数与指针返回值既然按值返回这么贵C98的程序员们自然要想办法绕过。最流行的方案有两个。第一个是输出参数void makeVec(std::vectorint out) { out.clear(); out.reserve(1000000); for (int i 0; i 1000000; i) { out.push_back(i); } }调用方负责预先构造一个vector对象函数内部直接往里面填数据。这种写法的好处是确实省掉了返回值相关的拷贝坏处也很明显接口的语义变得很模糊。void返回值让调用方一眼看不出来这个函数的目的是“产生一个新对象”还得靠参数命名去猜。而且这种写法没法做链式调用没法直接写auto result makeVec()这样自然的表达式代码的可读性明显下降。第二种方案是返回指针std::vectorint* makeVec() { std::vectorint* v new std::vectorint(); // 填充数据... return v; }这个方案虽然让返回值语义回归了但引入了一个更大的问题谁来负责delete如果调用方忘了释放内存泄漏如果函数内部抛出异常new出来的对象可能没人释放。后来auto_ptr和shared_ptr的出现缓解了资源管理问题但指针方案本质上还是在“转移所有权”和“拷贝开销”之间做选择——返回智能指针可以让资源安全但拷贝的代价仍然存在于类型内部。你可能会问当时编译器难道不会做返回值优化吗答案是编译器确实会做但是是“允许的优化”而非“保证的优化”。尤其对于return v;这种返回具名局部变量的情况编译器能不能做NRVO完全取决于实现标准并没有做出任何承诺。在那个依赖编译器“良心”的年代按值返回的代价是一个悬在所有C程序员头上的达摩克利斯之剑。2. C11的转折右值引用与移动语义2.1 一次“偷”代替“复印”移动语义的核心思想C11引入右值引用可以说是标准委员会对C性能模型的一次彻底反思。核心问题在于C98里我们无法区分“一个即将销毁的临时对象”和“一个还会继续使用的具名对象”。既然分不清编译器就只能用最保守的策略——拷贝。右值引用就是为了解决这个问题诞生的。它允许我们写一个专门接收“临时对象”的构造函数——移动构造函数这个函数可以“偷”走临时对象的内部资源而不是逐一复制。class MyBuffer { int* ptr; size_t size; public: MyBuffer(MyBuffer other) noexcept : ptr(other.ptr), size(other.size) { other.ptr nullptr; other.size 0; } };注意看这个移动构造函数它只是把other.ptr这个指针“拿”过来再把other的成员置空。整个过程没有一次数据复制时间复杂度是O(1)。这就是移动语义的核心思想——把一摞文件连同纸箱直接推给对方而不是复印一份新的。有一个细节特别容易踩坑移动之后必须把源对象的指针置为nullptr。如果忘了这一步other和当前对象会指向同一块内存等两个对象析构时会对同一块内存执行两次delete直接导致崩溃。我见过不少初学者写的移动构造函数犯这个错这属于“移动语义的经典陷阱”。2.2 返回值在C11/14的处境移动与省略的“二选一”有了移动语义之后按值返回局部对象的成本从O(n)降到了O(1)。因为当函数执行return v;时如果v是一个具名的局部变量编译器会优先把它当作右值来处理调用移动构造函数而不是拷贝构造函数。这就让std::vector、std::string这一类带堆内存的类型返回时只发生一次轻量级的指针交换。但C11/14时代返回值优化RVO仍然没有成为标准强制要求的优化。标准说的是“允许实现省略拷贝/移动操作”注意这里的用词是“允许”而非“必须”。这意味着什么意味着编译器在大多数情况下确实会做但你不能在代码里依赖它。这造成了C11/14时代一个很微妙的处境按值返回的代码实际执行的是“移动语义 RVO”的混合策略。大多数现代编译器GCC、Clang、MSVC在默认优化级别下都会做RVO所以很多情况下移动构造函数都不会被调用返回值直接被构造到了目标位置。但这毕竟不是标准承诺的行为。你写出来的代码换一个编译器、换一个优化级别可能就多了一次移动操作。这里有个容易产生误解的点移动虽然快但不代表零开销。对于std::string、std::vector来说移动是O(1)但对于std::array这种所有元素都存放在对象内部的类型根本没有“堆资源”可以偷移动等价于拷贝复杂度是O(n)。更极端的情况是std::tuple它的移动行为取决于其包含的所有成员是否都能高效移动。所以在C11/14时期按值返回的最优策略仍然是“尽量让编译器把你的代码优化成RVO”而不是依赖移动语义去补救。2.3 std::move与返回值的微妙关系讲到这里我必须插一个流传很广的反模式在return语句里写return std::move(x);。很多初学者学了移动语义之后特别激动觉得用std::move就能“让性能起飞”于是写出了这样的代码std::string foo() { std::string s hello; return std::move(s); // 反模式阻止了NRVO }这个写法的致命问题在于return std::move(s);返回的是一个右值引用表达式而不是一个具名变量。此时编译器针对“具名局部变量”的NRVO优化规则直接失效——因为它返回的不是变量本身而是移动操作的结果。于是本来可能发生的零成本省略变成了必然发生的一次移动操作。虽然移动比拷贝便宜但你亲手放弃了免费的机会这不是与优化背道而驰吗正确的写法非常简单std::string foo() { std::string s hello; return s; // 编译器先尝试NRVO如果不成功则隐式移动 }只有在一种情况下return std::move(...)是合理的当你返回的不是局部变量而是成员变量的时候。比如一个右值引用限定的成员函数class Widget { std::string name_; public: std::string getName() { return std::move(name_); // 成员变量不存在NRVO合理地转移资源 } };在这个场景里name_不是局部变量编译器无法对它做NRVO而且既然对象本身是右值说明它即将销毁把它的资源偷走是安全且合理的。除此之外return std::move(局部变量)几乎总是坏味道。3. C17的定音强制复制省略3.1 复制省略到底省略了什么C17最让人激动的改动之一就是“强制复制省略”mandatory copy elision进入了标准。要理解这个改动先要把“复制省略”copy elision这个术语拆开。它实际包含了两种不同场景的优化第一种是prvalue优化也叫纯右值优化。当函数返回一个临时对象时编译器直接把临时对象的构造放到调用方的目标位置。比如std::string make() { return std::string(hello); // 返回一个纯右值 }第二种是NRVO具名返回值优化。当函数返回一个具名局部变量时编译器把该变量直接构造到返回值的位置std::string make() { std::string s hello; return s; // 返回具名局部变量 }在C17之前这两种优化都是“允许的”——编译器可以选择做也可以选择不做。从C17开始prvalue优化成为强制性的规则当使用prvalue初始化一个对象时不经过任何临时物化直接在最终目标位置构造。NRVO则仍然停留在“允许的优化”层面。3.2 强制省略不再需要移动构造函数强制复制省略最直接的影响是如果函数返回一个右值表达式编译器可以不调用移动构造函数甚至完全不需要移动构造函数存在。来看一个在C11/14下根本无法编译的例子struct NonMovable { NonMovable() default; NonMovable(const NonMovable) delete; NonMovable(NonMovable) delete; }; NonMovable make() { return NonMovable{}; // C17合法因为强制省略不需要移动/拷贝 } int main() { auto obj make(); }这段代码在C17标准下可以正常编译运行。但在C11/14标准下编译器会毫不犹豫地报错NonMovable的移动构造函数和拷贝构造函数都被删除了它根本没有办法被“搬回”调用方。C17之后return NonMovable{};这句话的意思是“在调用方的目标位置直接构造一个NonMovable{}对象”整个过程不涉及任何搬移操作。为什么C17能达到这种效果根本原因在于C17重新调整了值类别模型。在C17中纯右值不再是一个“实体对象”而是一个“初始化行为”。当编译器看到一个纯右值表达式它知道这个表达式的目的是“在某个位置构造对象”。于是它可以直接把目标位置交给这个初始化过程省去临时对象这个中间环节。这其实是C标准演进中非常典型的一步为了很多其它目的调整了语言的基础语义返回值性能只是顺带的巨大红利。但对我们写代码的人来说重要的是一个认知转变——C17之后按值返回临时对象时拷贝和移动操作从“可能被优化掉”变成了“根本不存在”。3.3 强制省略对程序员意味着什么我在实际项目里体会最深的一点是C17之后写工厂函数和解析函数的心态完全不一样了。以前写一个函数返回一个复杂对象要先琢磨一下是不是有额外的拷贝或移动现在只要返回值是临时对象就可以放心地按值返回。比如std::vectorstd::string readTokens(std::string_view input) { std::vectorstd::string tokens; // ... 解析逻辑 return tokens; }注意这个函数返回的是具名局部变量tokens所以它依赖于NRVO非强制如果编译器没有做NRVO最坏情况也就是一次移动操作不会发生拷贝。而移动一个vector的代价是常数级别的可以接受。如果你写的是std::vectorstd::string readTokens(std::string_view input) { std::vectorstd::string tokens; // ... 解析逻辑 return std::move(tokens); // 反模式 }这就把本来可能是零成本的NRVO给“堵死”了还多一次移动调用。所以现代C的最佳实践是直接返回局部变量把优化机会留给编译器。从性能总量来看C98时代的一次按值返回可能是“三次完整拷贝”C11时代是“零或一次O(1)移动”C17时代是“纯右值场景零拷贝零移动具名场景零或一次O(1)移动”。这个演进完全称得上数量级层面的改善。4. 优化之外现代C函数返回值的工程决策4.1 三种返回方式的对比既然历史已经把技术路线铺到了这里我们该做的就是把决策模型梳理清楚。现代C里函数“把数据交给调用方”的主流方式有三种按值返回、输出参数、返回指针或智能指针。各自的适用场景完全不同。方式开销可读性适合场景按值返回C17下极低RVO/移动高符合直觉新对象、临时对象、工厂函数输出参数无拷贝但有预构造开销低调用方需先创建对象复用已有对象、池化对象返回智能指针指针本身零开销动态分配O(1)中语义清晰动态创建且所有权需转移的对象返回裸指针零开销差所有权不明非拥有关系的查询场景在C98时期输出参数和指针返回是为了“性能”而不得不做的妥协到了C17时代这两者应该回归到它们真正的使用场景——不是因为怕拷贝而是因为语义需要。4.2 一个关键的判断标准返回值是“新对象”还是“已有对象”这些年我帮团队做代码评审时总结出一个判断函数返回值写法的实用标准看返回值是一个“全新制造的对象”还是一个“已有的对象”。如果函数内部从头开始组装一个对象并把它交给调用方那它就是一个新对象。这种情况默认按值返回不要犹豫。编译器的RVO和移动语义会帮你兜底std::string readFileToString(std::string_view path); // 新对象按值返回 std::vectorint parseNumbers(std::string_view input); // 新对象按值返回如果函数要把数据填充进一个已经存在的对象里调用方明确需要复用一个预先分配好的资源这时输出参数才有意义。最典型的场景是对象池void acquireFromPool(PooledObject out);调用方从池里取一个对象希望尽可能复用底层内存这时候输出参数能避免每次调用都重新分配堆内存是一个真实的性能优化。这条标准的价值在于它把“返回值该用什么写法”从经验主义变成了一个可判断的问题。先看清楚是“新对象还是旧对象”再决定按值返回还是传引用基本不会犯方向性错误。4.3 那些年被误会的“性能优化”过早优化与可读性在这个话题下我必须泼一点冷水很多C程序员在函数返回值上做的“性能优化”其实都是过早优化。举个例子有人为了让一个函数避免一次移动写了极其复杂的重载组合和转发引用结果代码可读性严重下降而且实际运行时的性能差异在profiler里根本测不出来。这是典型的本末倒置。正确的工作流应该是先写清晰直观的代码默认按值返回然后通过profiler找出真正的热点最后才对热点函数做针对性的优化。如果一个函数不是热点它的返回值优化做得好不好对整体性能根本无关紧要。当然也有真的需要提前思考的场景比如一个每秒被调用几百万次的热点函数返回的是一个有堆内存分配的大对象这种情况下每一份拷贝都是真金白银的性能损失。但即便是这种场景C17的按值返回也已经足够好你需要关注的反而是一些更细节的东西——比如移动之后的空对象是否会有额外的分配行为、是否需要在移动构造函数里显式clear原对象等。这里顺带提一个容易被忽略的“移动不免费”案例std::vector的移动构造函数有一个前提条件两个vector的分配器必须相等。如果使用了带状态的分配器stateful allocatorstd::vector的移动就会退化为拷贝。这一点在某些老项目里真是坑过不少人——明明写了移动构造实际跑起来却像拷贝一样慢查了半天最后发现是分配器的问题。5. 常见问题与排查技巧实录5.1 如何验证你的代码是否发生了返回值优化很多读者可能会问我怎么知道我的代码到底有没有被RVO优化有一个非常简单实用的验证方法用一个累加器类打印所有关键函数的调用次数#include iostream struct Tracker { Tracker() { std::cout default ctor\n; } Tracker(const Tracker) { std::cout copy ctor\n; } Tracker(Tracker) noexcept { std::cout move ctor\n; } ~Tracker() { std::cout dtor\n; } }; Tracker make() { Tracker t; return t; } int main() { auto obj make(); }用默认优化编译例如g -stdc17 -O2 main.cpp你会看到输出只有default ctor dtor这里只发生了一次默认构造和一次析构说明NRVO生效了return t;的t被直接构造到了main里的obj位置没有中间移交。如果加上-fno-elide-constructors选项GCC/Clang特有用于关闭所有复制省略优化再编译你会看到default ctor move ctor move ctor dtor dtor dtor这次过程是t默认构造函数返回时移动构造了一次临时对象临时对象再移动构造到obj最后三个对象析构。这个对比就能直观地看出RVO帮我们省掉了几次操作。5.2 为什么我的NRVO没有被触发NRVO不是强制优化编译器在特定的场景下会选择放弃。我整理了在实际工作中最容易踩到的几种场景场景原因对策函数返回不同分支的不同对象编译器无法确定应该把哪个对象构造到目标位置重构为公共局部变量或接受一次移动不要强行用指针/输出参数返回的对象内部有指向自己的引用或指针可能存在别名问题省略后可能改变语义确保对象不自引用返回类型与局部变量类型不完全一致需要派生类到基类的转换无法直接构造接受一次移动关闭优化编译如-O0部分编译器在低优化级别下不做NRVO发布时使用正常优化级别这里要澄清一个容易过度担心的点即使NRVO失败输出的也不会是拷贝操作而是移动操作。在return local;这种写法下局部变量会被视为右值进行移动。移动一个vector的成本是几个指针交换完全没必要恐慌。5.3 return std::move陷阱的识别与规避前文已经详细讲过这个反模式这里我把它放到“问题排查”里再强调一次因为它真的太常见了。很多人学了移动语义之后对std::move产生了滥用倾向任何return都要move一下以为这样就是“最高效的写法”。实际恰恰相反。我亲身经历过的例子是团队里有一位同事把一个模块里的return语句全部改成了return std::move(local);理由是“这样移动更明确”。结果我用Tracker方法一测发现所有函数的定期析构次数都有多而且多出来的正是额外移动构造的临时对象。瞬间打脸。这里也顺带整理一个判断规则返回具名局部变量直接return local;让编译器做NRVO失败时自动移动。返回临时对象直接return T(...);或return {};C17是强制省略。返回成员变量不限局部如果这个对象不会再被使用可以用return std::move(member);。返回全局变量/静态变量直接返回引用或按值拷贝不要用std::move。5.4 在未开启C17时的兼容性策略虽然C17已经发布很多年但现实中确实还有一些项目因为历史原因停留在C11/14标准上。如果你的项目也是这样函数返回值的写法需要稍微保守一点。优先策略是尽量返回临时对象而不是具名局部变量。比如std::string foo() { return std::string(hello); // 临时对象编译器几乎总是会做RVO }尽量避免在返回语句之前对局部变量做复杂操作后再return因为那种情况下编译器做NRVO的难度会增加。比如多分支返回不同变量的场景即使在C17下也无法保证优化。再一个建议是如果你正在主导一个老项目的升级函数返回值优化可以作为“从C14升级到C17”的一个最直观的收益点。你什么都不用改光是把标准版本调上去return {};这类纯右值返回从“允许优化”变成了“强制优化”相当于白捡了一波性能提升。我个人在实际项目中的体会是这条“拷贝→移动→省略”的演进线其实也是在提醒我们C的性能从来不是靠某个单一奇技淫巧解决的而是靠语言机制本身在一次一次地演进。你不需要发明什么魔法只要跟着标准走——用现代写法写清晰的代码把优化交给编译器和标准本身。如果你准备面试这条历史线可以串起“C98的拷贝代价”“C11移动语义的核心思想”“为什么vector移动比array快”“return std::move什么时候是合理的”等一系列问题是一套很完整的知识体系。最后再分享一个小经验如果你真的关心一个函数的返回值是否产生了多余的构造调用不要靠猜直接把那个Tracker类丢进去跑一遍数据会告诉你答案。