This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

635. domain of allocator::address

Section: [allocator.requirements] Status: Resolved Submitter: Howard Hinnant Opened: 2007-02-08 Last modified: 2016-02-10

Priority: Not Prioritized

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with Resolved status.


The table of allocator requirements in [allocator.requirements] describes allocator::address as:


where r and s are described as:

a value of type X::reference obtained by the expression *p.

and p is

a value of type X::pointer, obtained by calling a1.allocate, where a1 == a

This all implies that to get the address of some value of type T that value must have been allocated by this allocator or a copy of it.

However sometimes container code needs to compare the address of an external value of type T with an internal value. For example list::remove(const T& t) may want to compare the address of the external value t with that of a value stored within the list. Similarly vector or deque insert may want to make similar comparisons (to check for self-referencing calls).

Mandating that allocator::address can only be called for values which the allocator allocated seems overly restrictive.

[ post San Francisco: ]

Pablo recommends NAD Editorial, solved by N2768.

[ 2009-04-28 Pablo adds: ]

Tentatively-ready NAD Editorial as fixed by N2768.

[ 2009-07 Frankfurt ]

Fixed by N2768.

[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2982.

Proposed resolution:

Change [allocator.requirements]:

r : a value of type X::reference obtained by the expression *p.

s : a value of type X::const_reference obtained by the expression *q or by conversion from a value r.

[ post Oxford: This would be rendered NAD Editorial by acceptance of N2257. ]

[ Kona (2007): This issue is section 8 of N2387. There was some discussion of it but no resolution to this issue was recorded. Moved to Open. ]