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

Question

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

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

截至目前,我的想法是这样的.

继续使用分配器的原因:

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

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

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

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

Answer 1

此时没有.

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

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

更重要的是,基于pmr的分配多年来一直没有被大量使用.任何弱点都可能会被曝光.

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