C++里那个“不负责构造”的迭代器：raw_storage_iterator到底在干啥？

你有没有写过这样的代码：用std::uninitialized_copy把一堆对象搬进一块裸内存里，结果编译器报错说“类型不满足 OutputIterator 要求”？或者更常见的是——你压根没听说过 raw_storage_iterator 这个名字，直到某天翻《C++标准库》附录时，它像一张泛黄的便签纸一样突然滑出来。

它不是热门选手，不常出现在教程里，连 Stack Overflow 上相关提问都不到三位数。但它干的事很实在：让一段未初始化的原始内存，假装自己是个能接收对象的输出迭代器。

这听上去有点“戏精”，但恰恰是它存在的全部意义。

raw_storage_iterator 的核心任务只有一个：转发赋值操作，但跳过构造。

我们习惯的 std::vector<T>::iterator 或 T*，往它身上写一个 T{...}，背后会触发 T 的拷贝/移动构造函数——这是对已构造对象的赋值（或重写）。而 raw_storage_iterator 面对的是一片 malloc 出来的、连 T 的构造函数都没见过的 raw bytes。它要做的，不是“赋值”，而是 placement new：在指定地址上原地构造对象。

所以它的 operator= 实际长这样（简化版）：

template<typename T>
raw_storage_iterator<T>& operator=(const T& value) {
    ::new (iter) T(value);  // 关键：不调用 *iter = ...，而是就地构造
    ++iter;
    return *this;
}

注意：它根本不碰 *iter 的左值语义，也不依赖 T 有 operator=；它只管“在这块地址上建一个新家”。

那什么时候真需要它？不是所有“搬内存”场景都需要。

举个具体例子：你手头有一块 char buffer[1024]，想把它当 Widget[128] 用，但又不想提前调用 128 次默认构造（比如 Widget 构造开销大，或根本不能默认构造）。这时你会：

1. 先 std::uninitialized_default_construct_n(buffer, 0) —— 先不构造；
2. 然后用 raw_storage_iterator<char*, Widget> 把一批 Widget 对象逐个“种”进去；
3. 最后统一析构时，得用 std::destroy_n，而不是 delete[]。

这个过程，绕开了容器封装，直连内存生命周期管理。它出现的地方，往往意味着你在写内存池、序列化缓冲区、自定义 allocator，或者调试 std::vector 内部扩容逻辑。

换句话说：当你开始关心“对象在哪块字节上出生”，raw_storage_iterator 就不再是冷知识，而是工具箱里一把带刻度的镊子。

容易踩的坑，也正来自它“假装得很像”的特性。

比如，有人试图这么写：

std::vector<Widget> src = {...};
std::vector<char> buf(src.size() * sizeof(Widget));
auto it = std::raw_storage_iterator(buf.data(), reinterpret_cast<Widget*>(buf.data()));
std::copy(src.begin(), src.end(), it); // ❌ 编译失败！

为什么？因为 std::copy 要求迭代器支持 *it = value，而 raw_storage_iterator 的 operator= 是 void operator=(const T&)，返回 raw_storage_iterator&，不返回 T& —— 它根本不符合传统输出迭代器对“可赋值性”的隐含假设。

真正该配对的是 std::uninitialized_copy：

std::uninitialized_copy(src.begin(), src.end(), it); // ✅

uninitialized_copy 明白：我给你的是一块空地，你只管盖房，别问砖是不是湿的。

还有一个常被忽略的细节：raw_storage_iterator 不管理内存所有权，也不记录容量。

它就像个施工队长，只管在你指的地址上盖第几栋楼，但不会提醒你“后面只剩两平米了”。越界？它不拦；重复构造？它不管；析构遗漏？它不背锅。这些全靠你用它的上下文来兜底。

所以实践中，它几乎从不单独出现。它总和三样东西绑定：

• 一块明确生命周期的原始内存（char* 或 aligned_storage_t）；
• 一个配套的 std::destroy / std::destroy_n 调用点；
• 一个清晰的“构造完成”标记（比如计数器或尾指针）。

少了其中任何一环，它就从工具变成隐患。

最后说句实在的：95% 的 C++ 日常开发，你确实不需要亲手调用 raw_storage_iterator。STL 容器、std::vector::reserve、std::string 的小字符串优化……它们内部可能悄悄用了它，但你不用看见。

但当你哪天要写一个零拷贝网络包解析器，或实现一个支持 move-only 类型的 ring buffer，又或者只是想看懂 libc++ 里 vector::_M_allocate 的注释时——那个名字略拗口、文档寥寥的 raw_storage_iterator，就会从标准库的角落里抬起头，安静地递给你一把钥匙。

它不炫技，不省事，甚至有点固执。但它诚实：我只做一件事，而且只在你确认安全的前提下，才动手。