This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 20.4.1 [mem.res.syn], 20.2.2 [memory.syn] Status: New Submitter: Jiang An Opened: 2022-02-28 Last modified: 2022-05-17
Priority: 4
View all issues with New status.
Discussion:
The issue reflected in LWG 3679 is not limited to <ranges> and
std::ranges::istream_view.
#include <vector>
// some standard headers other than <memory> and <memory_resource>
template<class T> my_ator {/*definition, meeting the requirements of Cpp17Allocator*/};
int main()
{
std::vector<int> v1; // Generally works. Is this guaranteed?
std::pmr::vector<int> v2; // Usually fails to work on libstdc++. Is this intendedly permitted??
std::vector<int, my_ator<int>> v3; // Generally works. Is this guaranteed?
}
Currently libstdc++ only provides forward declarations of std::pmr::polymorphic_allocator
in headers of standard allocator-aware containers, which means that users are required to include
both <memory_resource> and <vector> in order to create a
std::pmr::vector<T> object. If libstdc++ is technically conforming here, one may say
the definition of std::allocator is also not guaranteed to be available in these headers,
so <memory> is required to be included together with such a header to make
standard-container<T> work.
std::allocator_traits. If these containers are not guaranteed to work when the definition of
std::allocator_traits is not available, and the definition of std::allocator_traits
is not guaranteed to be provided in headers of these containers, then users are effectively always
required to include <memory> in order to create a container object, even if they are
using their own allocators.
[2022-05-17; Reflector poll]
Set priority to 4 after reflector poll.
Proposed resolution: