C++中如何用分配器(Allocator)实现new、delete及make_unique等效功能

实现正确性与注意点 #

你的整体实现逻辑是正确的，确实是用分配器封装new/delete/make_unique等效功能的可行方案，但有几个需要注意的隐患：

• allocator_make_unique的删除器捕获了分配器的左值引用，如果分配器的生命周期短于生成的unique_ptr，会出现悬空引用导致未定义行为。标准要求分配器是可拷贝构造的，更安全的做法是将分配器拷贝到删除器中，而非捕获引用。
• 当前实现仅支持单个对象的分配，没有处理数组场景，如果要对标完整的new[]/delete[]/数组版make_unique，还需要补充对应的偏特化实现。
• 你注释里提到的destroy要不要加try/catch的问题：C++标准默认约定析构函数应该为noexcept，如果析构函数抛出异常且没有被处理，程序会直接终止，这是符合通用设计预期的，不需要额外加try/catch强制释放内存，除非你有特殊的错误处理需求。

补充问题解答 #

你在补充1中的理解是对的，std::allocator_traits::construct会自动遵循uses-allocator构造约定：如果类型T是分配器感知类型（即定义了allocator_type内嵌类型，且构造函数支持std::allocator_arg_t标签分配器或者末尾参数接受分配器），construct会自动将你传入的分配器传递给T的构造函数，完成分配器的传播。

为什么标准库没有提供这类工具 #

主要有几个原因：

1. 分配器的初始设计定位就不是替代通用的new/delete，它的核心服务对象是标准容器，容器天然需要分离内存分配和对象构造的能力（比如vector预分配缓冲区时不需要构造对象），所以标准从一开始就没有考虑为通用单对象分配场景做封装。
2. 这类封装会引入类型兼容性问题：你实现的allocator_make_unique返回的是带自定义删除器的unique_ptr，和普通std::unique_ptr<T>不是同一个类型，无法互相赋值，会大幅增加使用上的复杂度。如果标准要加入这类工具，还要处理数组、对齐、分配器传播、异常处理等大量边缘场景，收益远低于成本。
3. 现有标准已经有替代方案：C11引入的std::allocate_shared可以直接用分配器创建shared_ptr，分配器会和控制块一起存储，返回的类型和普通std::shared_ptr<T>完全一致，不需要额外自定义删除器，已经覆盖了大部分需要带分配器的智能指针的场景。C17之后的多态内存资源（PMR）也进一步降低了自定义分配器的使用门槛。
4. 历史兼容包袱：C分配器接口从C98到C11到C17经过了三次大的修改，存在大量历史兼容问题，新增这类通用工具需要考虑的边界条件太多，标准委员会一直没有将其纳入优先级。

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