<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1318: N2982 removes previous allocator capabilities</title>
<meta property="og:title" content="Issue 1318: N2982 removes previous allocator capabilities">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1318.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#NAD">NAD</a> status.</em></p>
<h3 id="1318"><a href="lwg-closed.html#1318">1318</a>. N2982 removes previous allocator capabilities</h3>
<p><b>Section:</b> 20.2.9.2 <a href="https://wg21.link/allocator.traits.types">[allocator.traits.types]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2010-02-11 <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.traits.types">issues</a> in [allocator.traits.types].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Duplicate of:</b> <a href="lwg-closed.html#1375" title="reference_type should not have been removed from the
allocator requirements (Status: Dup)">1375</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-87</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
says that containers should have a nested typedef that defines their
<code>reference_type</code> as <code>value_type&amp;</code>; the previous
standard deferred to the allocator to define its
<code>reference_type</code>, and containers simply passed the allocator's
typedef on. This change is a mistake. Allocators should define both a
<code>pointer</code> type and a <code>reference</code> type. That's essential
for their original purpose, which was to make different memory models
transparent. If an allocator defines a <code>pointer</code> type that isn't
compatible with a normal pointer it also has to define a corresponding
<code>reference</code> type. For example (and please forgive a Windows-ism),
if an allocator's pointer is <code>T __far*</code>, then it's
<code>reference</code> has to be <code>T __far&amp;</code>. Otherwise everything
crashes (under the hood, references are pointers and have to have the
same memory access mechanics). Extensions such as this for more general
memory models were explicitly encouraged by C++03, and the allocator's
<code>pointer</code> and <code>reference</code> typedefs were the hooks for such
extensions. Removing the allocator's <code>reference</code> and
<code>const_reference</code> typedefs makes those extensions unimplementable
and breaks existing implementations that rely on those hooks.
</p>

<p><i>[
2010-02-25 Alisdair adds:
]</i></p>


<blockquote>
<p>
<code>vector&lt;bool&gt;::reference</code> is a nested class, and not a typedef.  It
should be removed from the list of containers when this change is made.
</p>

<p>
In general, I am uncomfortable placing this reference requirement on each
container, as I would prefer to require:
</p>

<blockquote><pre>
is_same&lt;Container::reference, Container::iterator::reference&gt;
</pre></blockquote>

<p>
This distinction is important, if we intend to support proxy iterators.  The
iterator paper in the pre-Pittsburgh mailing
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3046.html">N3046</a>)
does <em>not</em> make this proposal, but organises clause 24 in such a way this
will be much easier to specify.
</p>

<p>
The changes to clause 20 remain important for all the reasons Pete highlights.
</p>
</blockquote>

<p><i>[
2010 Batavia
]</i></p>


<p>
Removed <code>vector</code> from list of templates that should be adjusted as of meeting outcome.
</p>

<p><i>[
2010 post-Batavia
]</i></p>


<p>
Replaced <code>vector&lt;bool&gt;</code> reference by <code>vector</code> reference because of misinterpreting meeting typo.
Additional corrected numbering in P/R to N3225 wording.
</p>

<p><i>[
2010-12-06 Daniel reopens
]</i></p>


<p>
Unfortunately, the current P/R is defective for several reasons:
</p>
<ol>
<li> Table 43 &mdash; Descriptive variable definitions still contains three
references to <code>T&amp;</code>, namely in:
<blockquote>
<table border="1">
<tr>
<td>
<code>t</code>
</td>
<td>a value of type <code>const T&amp;</code></td>
</tr>
<tr>
<td>
<code>r</code>
</td>
<td>a value of type <code>T&amp;</code> obtained by the expression <code>*p</code></td>
</tr>
<tr>
<td>
<code>s</code>
</td>
<td>a value of type <code>const T&amp;</code> obtained by the expression <code>*q</code>
or by conversion from a value <code>r</code></td>
</tr>
</table>
</blockquote>
Especially the second and third items are misses in the 1318 P/R,
e.g. in N2723 or in C++03 these were referring
to <code>X::reference</code> and <code>X::const_reference</code>, resp.
None of them is referenced anywhere in the allocator requirements
table: <code>r</code> and <code>s</code> where historically needed to
define the expressions <code>a.address(r)</code> and <code>a.address(s)</code> which are gone now,
and <code>t</code> was needed to define the expression <code>a.construct(p, t)</code> which has been
replaced by <code>a.construct(p,args)</code>.
<p/>
The easiest fix seems to be to remove all three rows from Table 43.
</li>
<li>
Further-on, the current P/R suggests to replace the the current
definitions of the adaptor classes
<blockquote><pre>
stack
priority_queue
queue
</pre></blockquote>
similar to the other container types, i.e. to define <code>reference</code> and
<code>const_reference</code> now as
<blockquote><pre>
typedef typename allocator_traits&lt;Allocator&gt;::reference reference;
typedef typename allocator_traits&lt;Allocator&gt;::const_reference const_reference;
</pre></blockquote>
This would not only be an ill-formed definition (because there is no name
<code>Allocator</code> in scope), but it would also introduce a breakage compared to C++03,
where these definitions where already referring to the definition of the wrapped 
containers. So, the adaptor class templates should be removed from the current list.
</li>
<li>
Then the current P/R wording leads to one further unexpected and unwanted change due to 
the general formular used: <code>match_result::reference</code> is currently defined as
<blockquote><pre>
typedef const_reference reference;
</pre></blockquote>
because it is an <em>immutable</em> container (And we had this definition
already in N2723). The application of the rule would change this silently.
</li>
<li>
Finally the suggested wording for the <code>unordered_</code> containers is incomplete.
The reason is a current inconsistency between these containers and the rest: While
normally the definition of the pointer types is
<blockquote><pre>
typedef typename allocator_traits&lt;Allocator&gt;::pointer pointer;
typedef typename allocator_traits&lt;Allocator&gt;::const_pointer const_pointer;
</pre></blockquote>
for the unordered containers they are
<blockquote><pre>
typedef typename allocator_type::pointer pointer;
typedef typename allocator_type::const_pointer const_pointer;
</pre></blockquote>
These definitions are <em>not</em> equivalent, because allocators are no longer
required to define typedefs <code>pointer</code> and <code>const_pointer</code>, the
<code>allocator_traits</code> were invented as a further indirection to cope
with that. I.e. for the unordered containers we need to bring both the definition
of references <em>and</em> pointers in sync.
</li>
</ol>

<p><i>[
2011-02-23 Daniel updates the proposed wording with support from Pablo
]</i></p>


<p>The update attempts to fix the backward-compatibility problem that we have
introduced by ignoring the C++03 member function overloads <code>address</code>
of allocator types in C++0x completely. The resolution attempts to fix that
by adding these functions as optional members of allocators that are considered
first before falling back to <code>pointer_traits::pointer_to</code>. This still
allows us to remove the unused symbol <code>t</code> from the table, but we adapt
the symbols <code>r</code> and <code>s</code> to purely refer to the typenames
<code>reference</code> and <code>const_reference</code>.</p>

<p><i>[2011-03-06 Daniel adapts numbering to N3242]</i></p>


<p><i>[2011-03-11 Daniel removes <code>noexcept</code> specifiers from <code>address</code> functions]</i></p>


<p><i>[2011-03-12 Further wording improvements by Daniel and Pablo]</i></p>


<p><i>[2011-03-22 Madrid]</i></p>


<p>Closed as NAD, no consensus to make a change</p>



<p><b>Rationale:</b></p><p>No consensus to make a change</p>

<p id="res-1318"><b>Proposed resolution:</b></p>





</body>
</html>
