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.

### 578. purpose of hint to allocator::allocate()

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 `allocate` and not yet passed to member `deallocate`. The value hint may be used by an implementation to help improve performance 223). [Note: The value hint may be used by an implementation to help improve performance. -- end note]

> [Footnote: 223)In a container member function, the address of an adjacent element is often a good choice to pass for this argument.