定制容器类开发：是否需提供非多态分配器选项？

嘿，这是个非常实际的问题——毕竟咱们做开源工具，既要贴合自己的使用场景，也要考虑潜在用户的需求对吧？结合你的情况，我给你捋捋几个关键角度：

先明确你的容器定位 #

• 如果你的目标是让容器适配更广泛的C++代码生态：
  很多现有项目还在使用传统的模板式分配器（比如std::allocator，或者团队内部自定义的非pmr分配器）。支持模板参数传入分配器，能让这些项目无缝迁移到你的容器，几乎没有学习和适配成本。你完全可以参考标准容器的设计，把分配器设为可选模板参数，默认值可以设为pmr::polymorphic_allocator<T>，这样既保留pmr的便利性，也兼容传统分配器的使用场景。
• 如果你的容器核心优势和pmr深度绑定：
  比如你的容器就是为了配合内存资源池、动态切换分配策略的场景设计的，那完全可以专注于pmr::polymorphic_allocator。这样能大幅简化你的实现，不用处理模板分配器带来的各种特化、allocator_traits适配问题，代码会更简洁。但要注意，这可能会把习惯传统分配器的用户挡在门外，得权衡受众范围。

实现复杂度的权衡 #

• 支持模板分配器：需要遵循C++分配器的标准约定，比如使用std::allocator_traits来封装分配器的细节，还要处理一些边缘情况（比如分配器的拷贝、移动语义）。不过好在标准库已经有成熟的模式可以参考，比如std::vector的分配器接口，照搬过来就行，踩坑的概率不大。
• 只支持pmr分配器：实现会简单很多，pmr::polymorphic_allocator已经封装了多态分配的逻辑，你不用关心模板参数的各种变体，代码结构更清晰。

一个折中的小方案 #

你可以用模板参数默认值来兼顾两种场景，比如：

template <typename T, typename Allocator = pmr::polymorphic_allocator<T>>
class MyCustomContainer {
    // 容器实现代码
};

这样默认情况下用户用的是pmr分配器，有特殊需求的用户只需要显式传入自己的非多态分配器就行，完美平衡了便利性和兼容性。

另外提一句关于知识产权的问题：只要你周末开发的代码完全是独立编写，没有复用公司的代码片段、核心逻辑或者架构设计，就不属于公司IP，这点放心～

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