C++移动语义右值引用到底解决了什么
GreenShield
9 分钟阅读
移动语义解决的不是"能不能拷贝"，而是"能不能在明确不再需要原对象时，直接接管它的资源而不是逐字节复制"——这是 C++11 之前大对象传递的性能黑洞。当年写 std::vector<std::string> 做函数返回或插入，每一次都是深拷贝整段内存；移动语义让这些"即将消失的对象"把内部资源直接过继给接收方，拷贝开销从 O(n) 降到 O(1)。
左值、右值与引用的分类
能取地址、有名字的是左值；临时对象、字面量、即将消亡的是右值。T& 只能绑左值，const T& 左右都能绑但不允许改。C++11 引入 T&& 右值引用，专门绑右值，并且绑上之后可以合法地"掏空"它：
std::string make() { return "temporary"; }
std::string s = make(); // 触发移动而非拷贝
make() 返回的临时对象是右值，s 的构造优先匹配移动构造函数，把临时串内部的缓冲区指针直接挪过来，原临时串置空。整个过程没有复制一个字符。
移动构造函数长什么样
class Buffer {
size_t n;
int* data;
public:
Buffer(size_t sz) : n(sz), data(new int[sz]) {}
// 移动构造：接管 other 的资源
Buffer(Buffer&& other) noexcept
: n(other.n), data(other.data) {
other.n = 0;
other.data = nullptr; // 关键：让原对象处于可析构的空状态
}
~Buffer() { delete[] data; }
};
移动后 other 必须仍是合法可析构状态，否则两个对象析构时会 delete[] 同一块内存，双重释放直接崩溃。置空指针是移动语义的铁律——"掏空"不等于"销毁"，原对象还要走完它的析构。
移动解决了什么
容器扩容时，std::vector 把旧元素搬到新内存。没有移动语义只能逐元素拷贝，扩容一次成本随容量线性增长。有了移动，元素是 noexcept 可移动类型时直接"抢"资源，拷贝开销消失。
返回大对象不再被迫走返回值优化或堆分配。return std::move(x) 一般不要手写——编译器在返回局部变量时本就走移动，多写 move 反而可能抑制 RVO（返回值优化）。让编译器自己决定，它比你更懂何时该移动、何时该省略。
标准库容器之间赋值、插入、拼接，全靠移动语义提速。经验上，凡是管理堆资源的类型，移动都能把"传值/返回"从性能热点变成零成本操作。
完美转发与 std::move / forward
std::move 不"移动"任何东西，它只是把左值无条件转成右值引用，是对"我放弃这个对象"的声明。真正执行移动的是接收右值的构造函数或赋值运算符。把 std::move 用在还会被读取的对象上，是典型的未定义行为前兆。
模板里既要保留左右值性质，用 std::forward<T> 转发：
template <typename T>
void relay(T&& arg) { // T&& 在模板里是转发引用，可左右值都接
sink(std::forward<T>(arg));
}
std::forward 配合 T&& 的引用折叠规则，把"传入的是左值就当左值、右值就当右值"原样传递下去，避免一次多余拷贝。工厂函数、包装器、emplace 类接口都依赖这套机制，才能做到"按原值类别转发"。
边界与坑
noexcept 不是装饰。标准库容器在扩容时，只有移动构造是 noexcept 才敢用移动，否则为保证强异常安全会退回拷贝。忘写 noexcept 的移动构造，性能优化会悄悄失效——编译器无法证明移动不抛异常，就只能保守地拷贝。
被 std::move 之后的对象处于"有效但未指定状态"，只能析构或重新赋值，再读它的值是未定义行为。常见坑：移动完又去取 size() 当真值用，结果拿到 0。
const T&& 几乎没用：常量右值引用无法被移动（移动要改原对象），只会落回拷贝。函数参数若想支持移动，不要写成 const T&&。
引用折叠速记：& &、& &&、&& & 都折成 &，只有 && && 折成 &&。这套规则是 forward 能保住值类别的基础，也是模板里 T&& 既能接左值又能接右值的根本原因。
标准库类型（string、vector、unique_ptr 等）已自带正确的移动构造与移动赋值，自己写类时只要管理裸资源，就必须配对地实现移动构造、移动赋值，并显式或隐式地 =default 拷贝版本，否则规则五之一定义不全会导致拷贝被删除或移动被抑制。
移动赋值也要防自赋值：a = std::move(a) 这种写法，先 delete 自己的资源再访问已空的 other 会崩。标准做法是 if (this != &other) 守卫，或先 swap 再让对方析构旧资源。
移动语义不是银弹：对内置类型、小对象（如两三个 int 的结构体），移动和拷贝代价一样，强行引入右值引用反而增加阅读负担。判断标准是"该类型是否持有堆资源"——是，才值得为它写移动；否，普通拷贝或规则五的 =default 就够了。
移动语义与标准容器的协同
std::vector 的扩容最能体现移动的价值。当容量不足，vector 分配新缓冲并把旧元素搬过去：元素是 noexcept 可移动类型时，逐元素移动构造（只搬指针），否则退回逐元素拷贝（深复制整段内存）。所以把大结构体塞进 vector、又频繁 push_back 触发扩容，若没写对移动构造，性能会随容量线性恶化。经验上，持有 std::string、std::vector 成员的类，几乎都必须确认这些成员自带移动、且自己的移动构造 noexcept，否则容器操作退化成拷贝。
std::unique_ptr 是移动语义的旗舰用例：它不可拷贝、只能移动，从定义上禁止了两个指针指向同一资源。函数返回 unique_ptr、在容器间转移所有权都靠移动，编译期就杜绝了重复释放。std::move 一个 unique_ptr 后，原指针变 nullptr，再解引用直接崩——这正是"移动后原对象不可用"的活例子。
emplace_back 比 push_back(std::move(x)) 更进一步：它在容器内存里直接用参数构造元素，连一次移动都省。前提是类型有匹配的构造函数，否则仍会退回拷贝或报错。
常见误用速查
把 std::move 当作"让代码变快"的魔法，到处加，反而掩盖设计问题：频繁移动小对象、或移动后立即又用，既没收益又引入风险。只在"明确放弃原对象、且对象持有可转移资源"时使用。
返回局部变量时手写 return std::move(local) 是常见的反模式。局部变量在返回点本就会被移动（或经 RVO 省略），你写的 move 反而阻止了 RVO，平白多一次移动。正确写法就是 return local;。
移动构造没标 noexcept，容器扩容退回拷贝——这是"为什么我写了移动还是慢"的第一嫌疑。把移动构造、移动赋值都标 noexcept，是让标准库放心用移动的开关。
基类忘了 =default 移动，派生类移动时会调用基类的拷贝而非移动，链路越长损耗越隐蔽。规则五（析构、拷贝构造、拷贝赋值、移动构造、移动赋值）要整体考虑，不能只补一半。
重载 fun(T&&) 与 fun(const T&) 同时存在时，左值走后者、右值走前者，这正是"移动优先、拷贝兜底"的惯用法；只写一个 T&& 版本会让左值调用方编译失败，别漏掉 const T& 重载。理解这套后，移动语义就不再是语法炫技，而是写大对象容器、工厂、资源管理时默认会用的基本功。
浏览 0
点赞 0
评论 0