This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 16.4.4.6[allocator.requirements]Status:CD1Submitter: Martin SeborOpened: 2000-11-02Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withCD1 status.
Discussion:
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be ofany type. But the synopsis in 20.4.1 calls for allocator<>::address() tobe overloaded on reference and const_reference, which is ill-formed forall T = const U. In other words, this won't work:
template class std::allocator<const int>;
The obvious solution is to disallow specializations of allocators onconst types. However, while containers' elements are required to beassignable (which rules out specializations on const T's), I think thatallocators might perhaps be potentially useful for const values in othercontexts. So if allocators are to allow const types a partialspecialization of std::allocator<const T> would probably have to beprovided.
Proposed resolution:
Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from
any type
to
any non-const, non-reference type
[Redmond: previous proposed resolution was "any non-const,non-volatile, non-reference type". Got rid of the "non-volatile".]
Rationale:
Two resolutions were originally proposed: one that partiallyspecialized std::allocator for const types, and one that said anallocator's value type may not be const. The LWG chose the second.The first wouldn't be appropriate, because allocators are intended foruse by containers, and const value types don't work in containers.Encouraging the use of allocators with const value types would onlylead to unsafe code.
The original text for proposed resolution 2 was modified so that italso forbids volatile types and reference types.
[Curaçao: LWG double checked and believes volatile is correctlyexcluded from the PR.]