634. allocator.address() doesn't work for types overloading operator&

Section: 20.2.10.2 [allocator.members] Status: CD1 Submitter: Howard Hinnant Opened: 2007-02-07 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [allocator.members].

View all issues with CD1 status.

Duplicate of: 350

Discussion:

20.2.10.2 [allocator.members] says:

pointer address(reference x) const;

-1- Returns: &x.

20.2.10.2 [allocator.members] defines CopyConstructible which currently not only defines the semantics of copy construction, but also restricts what an overloaded operator& may do. I believe proposals are in the works (such as concepts and rvalue reference) to decouple these two requirements. Indeed it is not evident that we should disallow overloading operator& to return something other than the address of *this.

An example of when you want to overload operator& to return something other than the object's address is proxy references such as vector<bool> (or its replacement, currently code-named bit_vector). Taking the address of such a proxy reference should logically yield a proxy pointer, which when dereferenced, yields a copy of the original proxy reference again.

On the other hand, some code truly needs the address of an object, and not a proxy (typically for determining the identity of an object compared to a reference object). boost has long recognized this dilemma and solved it with boost::addressof. It appears to me that this would be useful functionality for the default allocator. Adopting this definition for allocator::address would free the standard of requiring anything special from types which overload operator&. Issue 580 is expected to make use of allocator::address mandatory for containers.

Proposed resolution:

Change 20.2.10.2 [allocator.members]:

pointer address(reference x) const;

-1- Returns: &x. The actual address of object referenced by x, even in the presence of an overloaded operator&.

const_pointer address(address(const_reference x) const;

-2- Returns: &x. The actual address of object referenced by x, even in the presence of an overloaded operator&.

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

[ Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which was subsequently split out into a separate paper N2436 for the purposes of voting. The resolution in N2436 addresses this issue. The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. ]