2. Boost Json Translation (zh_Hans)
3. Doc / Pages / Allocators / Background (adoc)
4. English
5. Zen

8 :38
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 233/10000 · 233
9 :42
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Polymorphic Allocators 22/10000 · 22
10 :44
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — {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: 211/10000 · 211
11 :53
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 278/10000 · 278
12 :63
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A polymorphic allocator constructs with a pointer to a memory resource: 71/10000 · 71
13 :70
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 378/10000 · 378
14 :81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 265/10000 · 265
15 :91
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 313/10000 · 313
16 :102
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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). 393/10000 · 393
17 :109
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Problem Statement 17/10000 · 17
18 :111
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We would like an allocator model using a single type `T` with the following properties: 87/10000 · 87
19 :114
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `T` is not a class template 27/10000 · 27
20 :115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `T` references a {ref_memory_resource} 38/10000 · 38
21 :116
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `T` supports both reference semantics or shared ownership 57/10000 · 57
22 :117
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `T` interoperates with code already using `std::pmr` 52/10000 · 52
23 :119
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 356/10000 · 356
The translation has come to an end.