新的C ++代码应该使用内存资源而不是分配器吗？

Question

C ++ 17将为我们带来std::pmr::memory_resource，这是一个分配和释放内存的干净界面。与Allocator概念不同，它仅仅 ，仅此而已。还有std::pmr::polymorphic_allocator将内存资源包装到经典分配器中，因此它可以与现有容器一起使用。

如果我要编写一个针对C ++ 17及更高版本的新容器（或其他需要大量内存的），我应该继续针对 Allocator 概念进行编程，还是使用更新的清洁抽象直接？

截至目前，我的想法是这样的。

继续使用分配器的原因：

• 它与标准库和现有代码一致。甚至新的std::pmr::*容器别名也继续使用分配器。
• 由于内存资源可以包装成std::pmr::polymorphic_allocator，因此分配器接口更通用，可以满足更多客户端的需求。
• 内存资源总是使用运行时多态，因此与分配器可以提供的零开销抽象相比，它们具有较小的额外运行时开销。
• 也许某人实际上需要分配器接口的其他部分（例如自定义指针类型），这些部分不能由纯内存资源提供。

开始使用内存资源而不是分配器的原因：

• 分配器界面很笨重，很难实现。 std::pmr::memory_resource界面干净简洁。
• 由于内存资源是多态的，因此它们不会影响容器的类型，这意味着更少的模板实例化（因此可能更快的编译和更小的可执行文件），并使我们能够将更多的代码移动到单独的翻译单元中。
• 如果对象使用内存资源，它总是可以通过将内存资源包装到std::pmr::polymorphic_allocator来实例化仍然使用分配器的子对象。反过来说比较困难。
• 无论如何，内存分配是一项相对工作密集的任务。相对而言，单个虚函数调用不会增加太多开销。

是否已经有关于如何有效使用新库功能的建议？

Answer 1

此时没有。

C ++中的分配器目前比以前容易得多。

它们提供pmr和经典分配器支持。

更重要的是，基于pmr的分配多年来一直没有被大量使用。任何弱点都可能仍然存在。

基于快速池的分配器，甚至是固定缓冲区或sbo扩展，可能会注意到虚拟化开销。