Skip to content

Commit ed11397

Browse files
committed
New issue from Jiang An: "Can std::pmr::polymorphic_allocator::construct just call std::uninitialized_construct_using_allocator?"
1 parent 4938207 commit ed11397

File tree

1 file changed

+70
-0
lines changed

1 file changed

+70
-0
lines changed

xml/issue4311.xml

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
<?xml version='1.0' encoding='utf-8' standalone='no'?>
2+
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
3+
4+
<issue num="4311" status="New">
5+
<title>Can `std::pmr::polymorphic_allocator::construct` just call `std::uninitialized_construct_using_allocator`?</title>
6+
<section>
7+
<sref ref="[mem.poly.allocator.mem]"/>
8+
</section>
9+
<submitter>Jiang An</submitter>
10+
<date>06 Aug 2025</date>
11+
<priority>99</priority>
12+
13+
<discussion>
14+
<p>
15+
This is closely related to LWG <iref ref="3901"/> but only affects arguably pathological cases.
16+
<p/>
17+
Uses-allocator construction for <i>cv</i>-qualified types needs to be well-formed, but it's
18+
questionable to require `polymorphic_allocator::construct` to support constructing objects via
19+
pointer to a <i>cv</i>-qualified type. LWG <iref ref="3870"/> banned such placement construction
20+
for `std::construct_at`, which is depended by `uninitialized_construct_using_allocator`.
21+
<p/>
22+
As a result, it seems non-conforming to just use `uninitialized_construct_using_allocator` in
23+
`polymorphic_allocator::construct` since C++20, because the latter is still required to handle
24+
<i>cv</i>-qualified target types. If the status quo is considered unintended and needed to be fixed,
25+
perhaps we can just respecify `polymorphic_allocator::construct` to use
26+
`uninitialized_construct_using_allocator`.
27+
</p>
28+
</discussion>
29+
30+
<resolution>
31+
<p>
32+
This wording is relative to this
33+
<a href="https://github.com/cplusplus/draft/actions/runs/16749320058/artifacts/3690555293">CD preview draft</a>.
34+
</p>
35+
36+
<ol>
37+
38+
<li><p>Modify <sref ref="[mem.poly.allocator.mem]"/> as indicated:</p>
39+
40+
<blockquote>
41+
<pre>
42+
template&lt;class T, class... Args&gt;
43+
void construct(T* p, Args&amp;&amp;... args);
44+
</pre>
45+
<blockquote>
46+
<p>
47+
-14- <i>Mandates</i>: <del>Uses-allocator construction of `T` with allocator `*this` (see
48+
<sref ref="[allocator.uses.construction]"/>) and constructor arguments
49+
<tt>std::forward&lt;Args&gt;(args)...</tt></del><ins><tt>uninitialized_construct_using_allocator(p,
50+
*this, std::forward&lt;Args&gt;(args)...)</tt></ins> is well-formed.
51+
<p/>
52+
-15- <i>Effects</i>: <del>Constructs a `T` object in the storage whose address is represented by
53+
`p` by uses-allocator construction with allocator `*this` and constructor arguments
54+
<tt>std::forward&lt;Args&gt;(args)...</tt>.</del><ins>Equivalent to:</ins>
55+
</p>
56+
<blockquote><pre>
57+
<ins>uninitialized_construct_using_allocator(p, *this, std::forward&lt;Args&gt;(args)...);</ins>
58+
</pre></blockquote>
59+
<p>
60+
<del>-16- <i>Throws</i>: Nothing unless the constructor for `T` throws.</del>
61+
</p>
62+
</blockquote>
63+
</blockquote>
64+
65+
</li>
66+
67+
</ol>
68+
</resolution>
69+
70+
</issue>

0 commit comments

Comments
 (0)