User avatar admin

Translation uploaded
The system of allocator traits, especially POCCA and POCMA,
The system of allocator traits, especially分配器特征机制，尤其是 POCCA and和 POCMA,，
06/05/2026
User avatar admin

Translation uploaded
Parameterizing the allocator on the element type is clumsy.
Parameterizing the allocator on the element type is clumsy.在元素类型上参数化分配器的方式显得笨拙。
06/05/2026
User avatar admin

Translation uploaded
The container must be a class template.
The container must be a class template.容器必须是一个类模板。
06/05/2026
User avatar admin

Translation uploaded
While the system works, it has some usability problems:
While the system works, it has some usability problems:尽管该机制能够正常工作，但仍存在一些可用性问题：
06/05/2026
User avatar admin

Translation uploaded
The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.
The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.标准分配器是{req_DefaultConstructible}。为支持有状态分配器，容器提供了额外的构造函数重载，接受一个分配器实例参数。
06/05/2026
User avatar admin

Translation uploaded
= 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}:
= 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背景 C++中分配器的第一个版本定义了名为{req_Allocator}的要求，并将每个标准容器设计为以分配器类型为模板参数的类模板。例如，以下是 {std_vector}: 的声明：
06/05/2026
User avatar admin

Resource updated
File “doc/pages/allocators/background_zh_Hans.adoc” was added. 06/05/2026
User avatar admin

String added in the repository
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 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.
06/05/2026
User avatar admin

String added in the repository
`T` interoperates with code already using `std::pmr`
`T` interoperates with code already using `std::pmr`
06/05/2026
User avatar admin

String added in the repository
`T` supports both reference semantics or shared ownership
`T` supports both reference semantics or shared ownership
06/05/2026
User avatar admin

String added in the repository
`T` references a {ref_memory_resource}
`T` references a {ref_memory_resource}
06/05/2026
User avatar admin

String added in the repository
`T` is not a class template
`T` is not a class template
06/05/2026
User avatar admin

String added in the repository
We would like an allocator model using a single type `T` with the following properties:
We would like an allocator model using a single type `T` with the following properties:
06/05/2026
User avatar admin

String added in the repository
Problem Statement
Problem Statement
06/05/2026
User avatar admin

String added in the repository
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).
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).
06/05/2026
User avatar admin

String added in the repository
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:
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:
06/05/2026
User avatar admin

String added in the repository
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:
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:
06/05/2026
User avatar admin

String added in the repository
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:
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:
06/05/2026
User avatar admin

String added in the repository
A polymorphic allocator constructs with a pointer to a memory resource:
A polymorphic allocator constructs with a pointer to a memory resource:
06/05/2026
User avatar admin

String added in the repository
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:
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:
06/05/2026

Search