This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 26.11 [specialized.algorithms], 20.3.2.2.7 [util.smartptr.shared.create] Status: C++11 Submitter: Alberto Ganesh Barbati Opened: 2008-07-14 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [specialized.algorithms].
View all other issues in [specialized.algorithms].
View all issues with C++11 status.
Discussion:
LWG issue 402(i) replaced "new" with "::new" in the placement
new-expression in 20.2.10.2 [allocator.members]. I believe the rationale
given in 402(i) applies also to the following other contexts:
in 26.11 [specialized.algorithms], all four algorithms unitialized_copy,
unitialized_copy_n, unitialized_fill and unitialized_fill_n use
the unqualified placement new-expression in some variation of the form:
new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);
in 20.3.2.2.7 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
new (pv) T(std::forward<Args>(args)...),
I suggest to add qualification in all those places. As far as I know, these are all the remaining places in the whole library that explicitly use a placement new-expression. Should other uses come out, they should be qualified as well.
As an aside, a qualified placement new-expression does not need
additional requirements to be compiled in a constrained context. By
adding qualification, the HasPlacementNew concept introduced recently in
N2677 (Foundational Concepts)
would no longer be needed by library and
should therefore be removed.
[ San Francisco: ]
Detlef: If we move this to Ready, it's likely that we'll forget about the side comment about the
HasPlacementNewconcept.
[ post San Francisco: ]
Daniel:
HasPlacementNewhas been removed from N2774 (Foundational Concepts).
Proposed resolution:
Replace "new" with "::new" in: