<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 634: allocator.address() doesn't work for types overloading operator&amp;</title>
<meta property="og:title" content="Issue 634: allocator.address() doesn't work for types overloading operator&amp;">
<meta property="og:description" content="C++ library issue. Status: CD1">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue634.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#CD1">CD1</a> status.</em></p>
<h3 id="634"><a href="lwg-defects.html#634">634</a>. <code>allocator.address()</code> doesn't work for types overloading <code>operator&amp;</code></h3>
<p><b>Section:</b> 20.2.10.2 <a href="https://wg21.link/allocator.members">[allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="lwg-closed.html#350" title="allocator&lt;&gt;::address (Status: Dup)">350</a></p>
<p><b>Discussion:</b></p>

<p>
20.2.10.2 <a href="https://wg21.link/allocator.members">[allocator.members]</a> says:
</p>
<blockquote>
<pre>pointer address(reference <i>x</i>) const;</pre>
<blockquote>
<p>
-1- <i>Returns:</i> <code>&amp;<i>x</i></code>.
</p>
</blockquote>
</blockquote>

<p>
20.2.10.2 <a href="https://wg21.link/allocator.members">[allocator.members]</a> defines <code>CopyConstructible</code> which currently not
only defines the semantics of copy construction, but also restricts what an overloaded
<code>operator&amp;</code> 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 <code>operator&amp;</code> to return something other
than the address of <code>*this</code>.
</p>

<p>
An example of when you want to overload <code>operator&amp;</code> to return something
other than the object's address is proxy references such as <code>vector&lt;bool&gt;</code>
(or its replacement, currently code-named <code>bit_vector</code>).  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.
</p>

<p>
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).
<a href="http://www.boost.org">boost</a> has long recognized this dilemma and solved it with 
<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><code>boost::addressof</code></a>.
It appears to me that this would be useful functionality for the default allocator.  Adopting
this definition for <code>allocator::address</code> would free the standard of requiring
anything special from types which overload <code>operator&amp;</code>.  Issue <a href="lwg-closed.html#580" title="unused allocator members (Status: NAD Editorial)">580</a><sup><a href="https://cplusplus.github.io/LWG/issue580" title="Latest snapshot">(i)</a></sup>
is expected to make use of <code>allocator::address</code> mandatory for containers.
</p>



<p id="res-634"><b>Proposed resolution:</b></p>
<p>
Change 20.2.10.2 <a href="https://wg21.link/allocator.members">[allocator.members]</a>:
</p>

<blockquote>
<pre>pointer address(reference <i>x</i>) const;</pre>
<blockquote>
<p>
-1- <i>Returns:</i> <del><code>&amp;<i>x</i></code>.</del> <ins>The actual address of object referenced by <i>x</i>,
even in the presence of an overloaded <code>operator&amp;</code>.</ins>
</p>
</blockquote>

<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
<blockquote>
<p>
-2- <i>Returns:</i> <del><code>&amp;<i>x</i></code>.</del> <ins>The actual address of object referenced by <i>x</i>,
even in the presence of an overloaded <code>operator&amp;</code>.</ins>
</p>
</blockquote>
</blockquote>

<p><i>[
post Oxford:  This would be rendered NAD Editorial by acceptance of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
]</i></p>


<p><i>[
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.
]</i></p>







</body>
</html>
