This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 20.2.10.2 [allocator.members] Status: CD1 Submitter: Martin Sebor Opened: 2006-05-17 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [allocator.members].
View all issues with CD1 status.
Discussion:
The description of the allocator member function
allocate() requires that the hint argument be
either 0 or a value previously returned from allocate().
Footnote 227 further suggests that containers may pass the address of
an adjacent element as this argument.
I believe that either the footnote is wrong or the normative
requirement that the argument be a value previously returned from a
call to allocate() is wrong. The latter is supported by
the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan
Myers. In addition, the hint is an ordinary void* and not the
pointer type returned by allocate(), with
the two types potentially being incompatible and the requirement
impossible to satisfy.
See also c++std-lib-14323 for some more context on where this came up (again).
Proposed resolution:
Remove the requirement in 20.6.1.1, p4 that the hint be a value
previously returned from allocate(). Specifically, change
the paragraph as follows:
Requires: hint either 0 or previously obtained from member
[Note: The value hint may be used by an
implementation to help improve performance. -- end note]
allocate and not yet passed to member deallocate.
The value hint may be used by an implementation to help improve performance
223).
[Footnote: 223)In a container member function, the address of an adjacent element is often a good choice to pass for this argument.