uninitialized_fill：给“空地”铺上第一层砖，而不是盖楼

你有没有试过给一块刚分配好的原始内存“填点东西”，却发现 std::fill 报错？或者更糟——程序跑着跑着就崩了，调试半天发现是往未构造对象的内存里写了值？

这不是编译器在跟你开玩笑，而是 C++ 在认真提醒你：内存 ≠ 对象。new char[100] 分配的是 100 字节的“空地”，不是 25 个 int 的“房间”。想在这块地上住人，得先打地基、砌墙、安门——也就是调用构造函数。uninitialized_fill 干的就是这个活：它不假设内存里已有有效对象，而是直接在裸内存上逐个构造新对象。

很多人第一次见到 uninitialized_fill，下意识觉得：“不就是 fill 多了个 uninitialized 吗？抄过去改个名就行？”——真这么干，轻则行为未定义，重则踩内存、析构崩溃。原因很简单：std::fill 假设目标迭代器指向的是已构造完成的对象，它直接调用 operator= 赋值；而 uninitialized_fill 面对的是一片“毛坯”，它调用的是 ::new (ptr) T(value) ——即就地构造（placement new）。

举个具体例子：

#include <memory>
#include <iostream>

struct Widget {
    int x;
    Widget(int v) : x(v) { std::cout << "ctor: " << x << "\n"; }
    ~Widget() { std::cout << "dtor: " << x << "\n"; }
};

int main() {
    // 分配原始内存：没有构造任何 Widget！
    void* raw = operator new(3 * sizeof(Widget));

    // ✅ 正确：用 uninitialized_fill 在 raw 上构造 3 个 Widget(42)
    Widget* p = static_cast<Widget*>(raw);
    std::uninitialized_fill(p, p + 3, Widget(42));

    // ❌ 错误：fill 会尝试调用 operator=，但 p[0] 根本没构造过！
    // std::fill(p, p + 3, Widget(99)); // UB！别这么写

    // 使用完后，必须显式析构 + 释放
    for (int i = 0; i < 3; ++i) {
        p[i].~Widget();
    }
    operator delete(raw);
}

输出会清晰显示三次构造，没有析构调用（因为 uninitialized_fill 只管建，不管拆）。这正是它的契约：只负责从无到有地初始化，不碰已有状态，也不承诺清理。

那什么时候非用它不可？常见于三类场景：

• 自定义容器实现：比如你手写一个 vector，reserve 后的内存是 raw 的，resize(n) 就得靠 uninitialized_fill 把新增位置填满；
• 内存池或对象池预热：提前批量构造一批对象，避免运行时反复调用构造函数带来的开销；
• 与 malloc/mmap 配合使用：系统级内存分配返回的永远是 raw 指针，C++ 对象语义必须由你亲手补全。

注意一个易被忽略的细节：uninitialized_fill 要求 T 是可复制构造的（CopyConstructible），但它不检查 T 是否 trivially copyable。如果 T 的拷贝构造函数有副作用（比如日志、计数、资源申请），uninitialized_fill 会老老实实执行它——这恰恰是设计意图：它尊重类型的完整构造语义，不走捷径。

反观 memcpy 或 std::copy，它们只做字节搬运，绕过构造函数。对 int、float 这类 trivial 类型当然快，但对 std::string、std::vector 就是灾难：你复制的是指针和长度，却没复制背后真正的堆内存，析构时双重释放几乎板上钉钉。

还有一点实用提醒：别试图用 uninitialized_fill 填充 const 对象。const T 的对象一旦构造完成就不能再修改，但 uninitialized_fill 构造时传入的是 const T& value，它只是把 value 的内容复制过去，构造本身是允许的。真正的问题出在后续：如果你之后想通过指针修改其中某个元素，编译器会拦住你——这是类型系统在尽责，不是 uninitialized_fill 的锅。

最后说个调试小技巧：当你怀疑某段内存操作出问题，不妨在构造/析构函数里加一行 std::cout << this << " ctor/dtor\n"。地址打印出来，一眼就能看出是不是同一块内存被重复构造，或者析构了未构造的对象——这种 bug 往往比逻辑错误更难定位，但 uninitialized_fill 的边界感，恰恰是帮你划清“谁该负责哪一段”的标尺。

uninitialized_fill 不是一个炫技的冷门函数，它是 C++ 内存管理链条中承上启下的关键一环：上接 raw memory，下启 fully-formed objects。理解它，不是为了多记一个算法，而是为了真正看懂——你写的每一行代码，究竟是在操作数据，还是在参与对象生命周期的缔造。

用好它，内存才不会变成无人认领的“鬼屋”。