Zen

Translation

Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
63/2330 · 233

Sign in to save translations.

English Chinese (Simplified Han script) Actions
= Background The first version of allocators in C++ defined the named requirement {req_Allocator}, and made each standard container a class template parameterized on the allocator type. For example, here is the declaration for {std_vector}:
= 背景 C++中分配器的第一个版本定义了名为{req_Allocator}的要求，并将每个标准容器设计为以分配器类型为模板参数的类模板。例如，以下是 {std_vector} 的声明：
The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.
标准分配器是{req_DefaultConstructible}。为支持有状态分配器，容器提供了额外的构造函数重载，接受一个分配器实例参数。
While the system works, it has some usability problems:
尽管该机制能够正常工作，但仍存在一些可用性问题：
The container must be a class template.
容器必须是一个类模板。
Parameterizing the allocator on the element type is clumsy.
在元素类型上参数化分配器的方式显得笨拙。
The system of allocator traits, especially POCCA and POCMA,
分配器特征机制，尤其是 POCCA 和 POCMA，
is complicated and error-prone.
是复杂且容易出错的。
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
使用多种分配器类型的基于分配器的程序会引发更多的函数模板实例化，且通常编译速度更慢，因为类模板的函数定义必须在所有调用点可见。
Polymorphic Allocators
多态分配器
{cpp}17 improves the allocator model by representing the low-level allocation operation with an abstract interface called {ref_memory_resource}, which is not parameterized on the element type, and has no traits:
{cpp}17通过引入一个名为 {ref_memory_resource} 的抽象接口来表示底层分配操作，从而改进分配器模型。该接口未在元素类型上参数化，且无特征：
The class template {ref_polymorphic_allocator} wraps a {ref_memory_resource} pointer and meets the requirements of {req_Allocator}, allowing it to be used where an allocator is expected. The standard provides type aliases using the polymorphic allocator for standard containers:
类模板{ref_polymorphic_allocator}包装了{ref_memory_resource}指针，并满足{req_Allocator}要求，使其可在需要分配器的地方使用。标准库为使用多态分配器的标准容器提供了类型别名：
A polymorphic allocator constructs with a pointer to a memory resource:
多态分配器通过一个指向内存资源的指针进行构造：
The memory resource is passed by pointer; ownership is not transferred. The caller is responsible for extending the lifetime of the memory resource until the last container which is using it goes out of scope, otherwise the behavior is undefined. Sometimes this is the correct model, such as in this example which uses a monotonic resource constructed from a local stack buffer:
内存资源通过指针传递；所有权不发生转移。调用方需负责确保该内存资源的生命周期持续到所有使用它的容器都离开作用域为止，否则行为未定义。在某些场景下，这种模型是合适的，例如以下示例中使用了一个基于局部栈缓冲区构造的单调内存资源：
However, sometimes shared ownership is needed. Specifically, that the lifetime extension of the memory resource should be automatic. For example, if a library wants to return a container which owns an instance of the library's custom memory resource as shown below:
然而，有时需要共享所有权，即内存资源的生命周期应自动延长。例如，若某个库希望返回一个容器，该容器拥有该库自定义内存资源的实例，如下所示：
This can be worked around by declaring the container to use a custom allocator (perhaps using a `std::shared_ptr< std::pmr::memory_resource >` as a data member). This hinders library composition; every library now exports unique, incompatible container types. A raw memory resource pointer is also easy to misuse:
可通过声明容器使用自定义分配器（可能使用`std::shared_ptr&lt; std::pmr::memory_resource &gt;`作为数据成员）来解决此问题。这会阻碍库的组合；每个库都会导出各自独特且互不兼容的容器类型。原始内存资源指针也容易被误用：
Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr<std::pmr::memory_resource>` which the caller must manage. Or the library could change its function signatures to accept a {ref_memory_resource}``*`` provided by the caller, where the library also makes public the desired memory resources (`my_resource` above).
针对此问题的变通方案往往比问题本身更糟糕。该库可以返回一个包含 vector 和`std::unique_ptr<std::pmr::memory_resource>`的pair，必须由调用方自行管理。或者，该库也可以修改其函数签名，接受调用方提供的{ref_memory_resource}``*``，同时将所需的内存资源（如上文的`my_resource`）公开。</std::pmr::memory_resource>
Problem Statement
问题陈述
We would like an allocator model using a single type `T` with the following properties:
我们希望采用一种使用单一类型`T`的分配器模型，该模型具有以下特性：
`T` is not a class template
`T`不是类模板
`T` references a {ref_memory_resource}
`T`引用一个 {ref_memory_resource}
`T` supports both reference semantics or shared ownership
`T`同时支持引用语义和共享所有权
`T` interoperates with code already using `std::pmr`
`T`能与已使用`std::pmr`的代码互操作
Boost.JSON solves this problem by introducing a new smart pointer called <<ref_storage_ptr>> which builds upon {cpp}17's memory allocation interfaces, accomplishing the goals above. As a result, libraries which use this type compose more easily and enjoy faster compilation, as member functions for containers which use the type can be defined out-of-line.
Boost.JSON通过引入一个名为&lt;<ref_storage_ptr>&gt; 的新型智能指针解决此问题，该指针基于{cpp}17的内存分配接口构建，实现了上述目标。因此，使用该类型的库更易于组合，并能获得更快的编译速度，因为使用该类型的容器的成员函数可以定义在类外（out-of-line）。</ref_storage_ptr>
English Chinese (Simplified Han script) Actions
While the system works, it has some usability problems:
尽管该机制能够正常工作，但仍存在一些可用性问题：
The container must be a class template.
容器必须是一个类模板。
Parameterizing the allocator on the element type is clumsy.
在元素类型上参数化分配器的方式显得笨拙。
The system of allocator traits, especially POCCA and POCMA,
分配器特征机制，尤其是 POCCA 和 POCMA，
is complicated and error-prone.
是复杂且容易出错的。
Polymorphic Allocators
多态分配器
The class template {ref_polymorphic_allocator} wraps a {ref_memory_resource} pointer and meets the requirements of {req_Allocator}, allowing it to be used where an allocator is expected. The standard provides type aliases using the polymorphic allocator for standard containers:
类模板{ref_polymorphic_allocator}包装了{ref_memory_resource}指针，并满足{req_Allocator}要求，使其可在需要分配器的地方使用。标准库为使用多态分配器的标准容器提供了类型别名：
A polymorphic allocator constructs with a pointer to a memory resource:
多态分配器通过一个指向内存资源的指针进行构造：
= Background The first version of allocators in C++ defined the named requirement {req_Allocator}, and made each standard container a class template parameterized on the allocator type. For example, here is the declaration for {std_vector}:
= 背景 C++中分配器的第一个版本定义了名为{req_Allocator}的要求，并将每个标准容器设计为以分配器类型为模板参数的类模板。例如，以下是 {std_vector} 的声明：
The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.
标准分配器是{req_DefaultConstructible}。为支持有状态分配器，容器提供了额外的构造函数重载，接受一个分配器实例参数。
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
使用多种分配器类型的基于分配器的程序会引发更多的函数模板实例化，且通常编译速度更慢，因为类模板的函数定义必须在所有调用点可见。
{cpp}17 improves the allocator model by representing the low-level allocation operation with an abstract interface called {ref_memory_resource}, which is not parameterized on the element type, and has no traits:
{cpp}17通过引入一个名为 {ref_memory_resource} 的抽象接口来表示底层分配操作，从而改进分配器模型。该接口未在元素类型上参数化，且无特征：
The memory resource is passed by pointer; ownership is not transferred. The caller is responsible for extending the lifetime of the memory resource until the last container which is using it goes out of scope, otherwise the behavior is undefined. Sometimes this is the correct model, such as in this example which uses a monotonic resource constructed from a local stack buffer:
内存资源通过指针传递；所有权不发生转移。调用方需负责确保该内存资源的生命周期持续到所有使用它的容器都离开作用域为止，否则行为未定义。在某些场景下，这种模型是合适的，例如以下示例中使用了一个基于局部栈缓冲区构造的单调内存资源：
However, sometimes shared ownership is needed. Specifically, that the lifetime extension of the memory resource should be automatic. For example, if a library wants to return a container which owns an instance of the library's custom memory resource as shown below:
然而，有时需要共享所有权，即内存资源的生命周期应自动延长。例如，若某个库希望返回一个容器，该容器拥有该库自定义内存资源的实例，如下所示：
This can be worked around by declaring the container to use a custom allocator (perhaps using a `std::shared_ptr< std::pmr::memory_resource >` as a data member). This hinders library composition; every library now exports unique, incompatible container types. A raw memory resource pointer is also easy to misuse:
可通过声明容器使用自定义分配器（可能使用`std::shared_ptr&lt; std::pmr::memory_resource &gt;`作为数据成员）来解决此问题。这会阻碍库的组合；每个库都会导出各自独特且互不兼容的容器类型。原始内存资源指针也容易被误用：
Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr<std::pmr::memory_resource>` which the caller must manage. Or the library could change its function signatures to accept a {ref_memory_resource}``*`` provided by the caller, where the library also makes public the desired memory resources (`my_resource` above).
针对此问题的变通方案往往比问题本身更糟糕。该库可以返回一个包含 vector 和`std::unique_ptr<std::pmr::memory_resource>`的pair，必须由调用方自行管理。或者，该库也可以修改其函数签名，接受调用方提供的{ref_memory_resource}``*``，同时将所需的内存资源（如上文的`my_resource`）公开。</std::pmr::memory_resource>
Problem Statement
问题陈述
We would like an allocator model using a single type `T` with the following properties:
我们希望采用一种使用单一类型`T`的分配器模型，该模型具有以下特性：
`T` is not a class template
`T`不是类模板
`T` references a {ref_memory_resource}
`T`引用一个 {ref_memory_resource}
`T` supports both reference semantics or shared ownership
`T`同时支持引用语义和共享所有权
`T` interoperates with code already using `std::pmr`
`T`能与已使用`std::pmr`的代码互操作
Boost.JSON solves this problem by introducing a new smart pointer called <<ref_storage_ptr>> which builds upon {cpp}17's memory allocation interfaces, accomplishing the goals above. As a result, libraries which use this type compose more easily and enjoy faster compilation, as member functions for containers which use the type can be defined out-of-line.
Boost.JSON通过引入一个名为&lt;<ref_storage_ptr>&gt; 的新型智能指针解决此问题，该指针基于{cpp}17的内存分配接口构建，实现了上述目标。因此，使用该类型的库更易于组合，并能获得更快的编译速度，因为使用该类型的容器的成员函数可以定义在类外（out-of-line）。</ref_storage_ptr>

Loading…

User avatar admin

Translation uploaded
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.使用多种分配器类型的基于分配器的程序会引发更多的函数模板实例化，且通常编译速度更慢，因为类模板的函数定义必须在所有调用点可见。
06/05/2026
User avatar admin

String added in the repository
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
Allocator-based programs which use multiple allocator types incur a greater number of function template instantiations and are generally slower to compile because class template function definitions must be visible at all call sites.
06/05/2026
Browse all string changes

Glossary

English Chinese (Simplified Han script)
No related strings found in the glossary.

String information

Flags
safe-html, strict-same
Unit identifier
42769
Source string location
:38
String age
06/05/2026
Last updated
06/06/2026
Source string age
06/05/2026
Translation file AsciiDoc file
doc/pages/allocators/background_zh_Hans.adoc, string 8