c++oding="utf-8" ?>
std::rotate是首选，因其专为区间移动设计，通过三次反转实现o(n)时间、o(1)空间的原地操作，对pod和非pod类型均安全且零额外拷贝。
用 std::rotate，别手写循环或 memcpy —— 它专为区间移动设计，且对 POD 和非 POD 类型都安全、零额外拷贝。
为什么 std::rotate 是首选
数组区间移动（比如把 [a,b,c,d,e] 中的 [b,c] 移到末尾变成 [a,d,e,b,c]）本质是三段逆序问题。手写 for 循环易错，memcpy 仅适用于 trivial 类型且需手动计算偏移，而 std::rotate 在标准库中已做最优实现：内部使用三次 std::reverse 或针对随机访问迭代器做原地块交换，不构造新对象，也不调用无关的拷贝/移动操作。
常见错误现象：std::copy + std::copy_backward 组合容易越界或覆盖；自己用 memmove 忘记检查类型是否 trivial，导致非 POD 类型析构/构造逻辑被跳过。
使用场景：
- 实现 deque 的中间插入/删除
- 滑动窗口重定位缓冲区
- 排序算法中 partition 后的子区间调整
std::rotate 的参数和边界行为
函数原型：std::rotate(first, middle, last)，效果是将 [first, middle) 挪到 [middle, last) 后面，等价于“以 middle 为分界点左旋”。注意：所有迭代器必须属于同一容器，且 first ≤ middle ≤ last。
容易踩的坑：
-
middle不能等于last（否则行为未定义），但可以等于first（此时无操作） - 若用在
std::vector上，移动后迭代器（除被旋转区间内）仍有效；但std::deque的迭代器在 rotate 后可能失效（取决于实现） - 对
std::list调用std::rotate效率低（O(n) 遍历找节点），应改用list::splice
示例：把 vector 中索引 2~4 的元素移到开头
std::vector<int> v = {0,1,2,3,4,5};
std::rotate(v.begin(), v.begin() + 2, v.begin() + 5); // [2,3,4,0,1,5]</int>
非随机访问容器怎么办
std::rotate 要求前向迭代器，但性能依赖于随机访问。对 std::forward_list 或自定义链表，它会退化成 O(n²) —— 此时应避免通用算法，改用容器特有接口：
-
std::forward_list::splice_after：O(1) 搬运节点，不调用任何构造/析构 -
std::list::splice：同样 O(1)，支持指定位置插入整个区间 - 切忌对
std::forward_list先转成 vector 再 rotate —— 多一次遍历 + 内存分配，完全违背“不产生多余拷贝”目标
性能影响：在 std::vector<:string></:string> 上用 std::rotate，只会移动 string 对象的内部指针（移动语义启用时），不会复制每个字符串内容；若禁用移动语义（如 old ABI），则触发 string 的移动构造，仍是常数次操作，而非线性次拷贝。
编译器和 STL 实现差异要注意什么
libc++ 和 libstdc++ 都对 std::rotate 做了优化，但 MSVC 的早期版本（
- 如果容器元素类型没有 noexcept 移动构造函数，
std::rotate可能回退到拷贝方式（C++11 起标准允许），此时需确保移动构造函数标记为noexcept - 某些嵌入式 STL（如 newlib）可能未实现完整优化，建议实测
std::rotate与手写三步 reverse 的耗时对比 - 不要试图用
std::memmove替代 —— 它不调用析构/构造，对含虚函数表或智能指针的类必崩
最常被忽略的一点：rotate 操作本身不改变容器 size，但如果你在 rotate 前后误用了 reserve 或 shrink_to_fit，就引入了隐式内存重分配 —— 这种“多余拷贝”不是 rotate 导致的，而是周边操作埋的雷。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
