<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="f1a8367f304a0723" weblate-flags="read-only, safe-html, strict-same">
        <source>= 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}:</source>
        <target state="translated">= 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}:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">11</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c911bfe8607b2d7f" weblate-flags="read-only, safe-html, strict-same">
        <source>The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.</source>
        <target state="translated">The standard allocator is {req_DefaultConstructible}. To support stateful allocators, containers provide additional constructor overloads taking an allocator instance parameter.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc1b23b12d903cfb" weblate-flags="read-only, safe-html, strict-same">
        <source>While the system works, it has some usability problems:</source>
        <target state="translated">While the system works, it has some usability problems:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">31</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6c60de6a9ab6cc1b" weblate-flags="read-only, safe-html, strict-same">
        <source>The container must be a class template.</source>
        <target state="translated">The container must be a class template.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">33</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a03ad2e2ad385ffc" weblate-flags="read-only, safe-html, strict-same">
        <source>Parameterizing the allocator on the element type is clumsy.</source>
        <target state="translated">Parameterizing the allocator on the element type is clumsy.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">34</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5226384777a007c5" weblate-flags="read-only, safe-html, strict-same">
        <source>The system of allocator traits, especially POCCA and POCMA,</source>
        <target state="translated">The system of allocator traits, especially POCCA and POCMA,</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="876c8d7cae93663c" weblate-flags="read-only, safe-html, strict-same">
        <source>is complicated and error-prone.</source>
        <target state="translated">is complicated and error-prone.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">36</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="672631018b430cec" weblate-flags="read-only, safe-html, strict-same">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">38</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="57ee2b373435b1f7" weblate-flags="read-only, safe-html, strict-same">
        <source>Polymorphic Allocators</source>
        <target state="translated">Polymorphic Allocators</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ca99023583eb3f58" weblate-flags="read-only, safe-html, strict-same">
        <source>{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:</source>
        <target state="translated">{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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">44</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3f23b95c6eea0e0e" weblate-flags="read-only, safe-html, strict-same">
        <source>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:</source>
        <target state="translated">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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="480d4e6d9b989693" weblate-flags="read-only, safe-html, strict-same">
        <source>A polymorphic allocator constructs with a pointer to a memory resource:</source>
        <target state="translated">A polymorphic allocator constructs with a pointer to a memory resource:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">63</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92193f3cdd626efd" weblate-flags="read-only, safe-html, strict-same">
        <source>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:</source>
        <target state="translated">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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">70</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="104ff11f1f2a93b6" weblate-flags="read-only, safe-html, strict-same">
        <source>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:</source>
        <target state="translated">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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">81</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87dc8128071bd84f" weblate-flags="read-only, safe-html, strict-same">
        <source>This can be worked around by declaring the container to use a custom allocator (perhaps using a `std::shared_ptr&lt; std::pmr::memory_resource &gt;` 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:</source>
        <target state="translated">This can be worked around by declaring the container to use a custom allocator (perhaps using a `std::shared_ptr&lt; std::pmr::memory_resource &gt;` 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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">91</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f02af4636a06f8f" weblate-flags="read-only, safe-html, strict-same">
        <source>Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr&lt;std::pmr::memory_resource&gt;` 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).</source>
        <target state="translated">Workarounds for this problem are worse than the problem itself. The library could return a pair with the vector and `std::unique_ptr&lt;std::pmr::memory_resource&gt;` 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).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">102</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5024b625fa92112a" weblate-flags="read-only, safe-html, strict-same">
        <source>Problem Statement</source>
        <target state="translated">Problem Statement</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9dbb29613cc6c6c7" weblate-flags="read-only, safe-html, strict-same">
        <source>We would like an allocator model using a single type `T` with the following properties:</source>
        <target state="translated">We would like an allocator model using a single type `T` with the following properties:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">111</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3acced75cdcdb5c0" weblate-flags="read-only, safe-html, strict-same">
        <source>`T` is not a class template</source>
        <target state="translated">`T` is not a class template</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">114</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="949b54164822d3ae" weblate-flags="read-only, safe-html, strict-same">
        <source>`T` references a {ref_memory_resource}</source>
        <target state="translated">`T` references a {ref_memory_resource}</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">115</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="88ea0578d4558e3e" weblate-flags="read-only, safe-html, strict-same">
        <source>`T` supports both reference semantics or shared ownership</source>
        <target state="translated">`T` supports both reference semantics or shared ownership</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">116</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="736dc967c7ac172c" weblate-flags="read-only, safe-html, strict-same">
        <source>`T` interoperates with code already using `std::pmr`</source>
        <target state="translated">`T` interoperates with code already using `std::pmr`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">117</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e738c249b5a0baea" weblate-flags="read-only, safe-html, strict-same">
        <source>Boost.JSON solves this problem by introducing a new smart pointer called &lt;&lt;ref_storage_ptr&gt;&gt; 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.</source>
        <target state="translated">Boost.JSON solves this problem by introducing a new smart pointer called &lt;&lt;ref_storage_ptr&gt;&gt; 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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile"></context>
          <context context-type="linenumber">119</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
