This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 16.4.4.6 [allocator.requirements] Status: NAD Submitter: Dhruv Matani Opened: 2004-10-17 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with NAD status.
Discussion:
The standard's version of allocator::construct(pointer, const_reference) severely limits what you can construct using this function. Say you can construct a socket from a file descriptor. Now, using this syntax, I first have to manually construct a socket from the fd, and then pass the constructed socket to the construct() function so it will just to an uninitialized copy of the socket I manually constructed. Now it may not always be possible to copy construct a socket eh! So, I feel that the changes should go in the allocator::construct(), making it:
template<typename T>
struct allocator{
template<typename T1>
void construct(pointer T1 const& rt1);
};
Now, the ctor of the class T which matches the one that takes a T1 can be called! Doesn't that sound great?
Proposed resolution:
Rationale:
NAD. STL uses copying all the time, and making it possible for allocators to construct noncopyable objects is useless in the absence of corresponding container changes. We might consider this as part of a larger redesign of STL.