最优返回复制值：libstdc++中concat实现的性能差异疑问

这确实是个反直觉但值得深究的问题，背后藏着C标准里值类别、复制消除规则，以及libstdc对非平凡类（比如std::string）的具体实现细节。

先拆解最优实现的逻辑 #

假设你的第一种实现是类似这样的：

template <typename T>
T concat(const T& a, const T& b) {
    T result(a);  // 1. 一次复制构造
    result += b;  // 2. 一次operator+=
    return result;
}

这里的核心是命名返回值优化（NRVO）：当函数返回一个命名的局部对象时，编译器有权直接在调用方的内存空间中构造这个对象，完全消除返回时的复制/移动操作。也就是说，result从一开始就被放在了调用方预期接收返回值的位置，所以整个过程只需要一次复制构造（从a到result）和一次operator+=，没有额外开销。

其他实现为什么会触发额外构造？ #

我们拿几种常见的替代实现举例分析：

实现1：返回临时对象的链式调用

template <typename T>
T concat(const T& a, const T& b) {
    return T(a) += b;
}

这里T(a)是一个临时对象（右值），调用operator+=后返回的是这个临时对象的左值引用。当函数返回这个引用时，编译器需要把临时对象的内容转移到返回值位置——虽然C++11及以后可以用移动构造，但移动构造依然是一次额外的函数调用（哪怕它很高效），且某些场景下编译器无法消除这个移动操作。

实现2：直接返回a + b

template <typename T>
T concat(const T& a, const T& b) {
    return a + b;
}

a + b本身会生成一个临时对象（因为operator+的语义就是返回新构造的对象），即便这里能触发返回值优化（RVO），operator+内部也需要先复制a、再追加b，本质上和第一种实现的逻辑类似，但如果libstdc++对operator+的实现没有做和operator+=一样的原地优化，或者临时对象的内存分配路径不同，就会额外引入构造开销。

实现3：默认构造后赋值

template <typename T>
T concat(const T& a, const T& b) {
    T result;
    result = a;
    result += b;
    return result;
}

这种写法会多一次默认构造和赋值操作，默认构造可能会初始化内存（比如std::string的小字符串缓冲区），赋值又会覆盖这些内容，完全是额外的无效操作，自然比第一种实现低效。

为什么你会以为所有实现都一样？ #

这是因为我们很容易忽略值类别对复制消除的影响：NRVO只适用于命名的局部对象，临时对象的RVO虽然存在，但不是所有场景都能触发；再加上不同操作的语义差异（operator+=是原地修改，operator+是生成新对象），以及libstdc++对非平凡类的底层优化（比如小字符串优化SSO的不同处理分支），最终导致不同实现的性能差异。

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