Content-Length: 6142 | pFad | https://cplusplus.github.io/LWG/issue578

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 ²²³⁾. [Note: The value hint may be used by an implementation to help improve performance. -- end note]

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