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

Should new C++ code use memory resources instead of allocators?

本文关键字：分配器 资源 内存 代码 c++ 新的      更新时间：2023-10-16

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中来实例化一个仍然使用分配器的子对象。
    • 无论如何，内存分配是一项相对工作密集型的任务。相对而言，单个虚函数调用不会增加太多开销。

关于如何有效地使用新的库特性，是否已经存在任何建议?

此时no.

c++中的分配器现在比以前容易多了。

它们提供pmr(多态)和经典分配器支持。

更重要的是，基于pmr的分配多年来没有大量使用。任何弱点都可能暴露。

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

相关文章：