<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1211: Move iterators should be restricted as input iterators</title>
<meta property="og:title" content="Issue 1211: Move iterators should be restricted as input iterators">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1211.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#Resolved">Resolved</a> status.</em></p>
<h3 id="1211"><a href="lwg-defects.html#1211">1211</a>. Move iterators should be restricted as input iterators</h3>
<p><b>Section:</b> 24.5.4.2 <a href="https://wg21.link/move.iterator">[move.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-18 <b>Last modified:</b> 2016-05-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#move.iterator">active issues</a> in [move.iterator].</p>
<p><b>View all other</b> <a href="lwg-index.html#move.iterator">issues</a> in [move.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I contend that while we can support both bidirectional and random access
traversal, the category of a move iterator should never be better than
<code>input_iterator_tag</code>.
</p>

<p>
The contentious point is that you cannot truly have a multipass property
when values are moved from a range.  This is contentious if you view a
moved-from object as still holding a valid value within the range.  
</p>

<p>
The second reason comes from the Forward Iterator requirements table:
</p>

<blockquote>
<p>
Forward iterators 24.3.5.5 <a href="https://wg21.link/forward.iterators">[forward.iterators]</a>
</p>

<p>
Table 102 &mdash; Forward iterator requirements
</p>

<blockquote><p>
For expression <code>*a</code> the return type is:
"<code>T&amp;</code> if <code>X</code> is mutable, otherwise <code>const T&amp;</code>"
</p></blockquote>
</blockquote>

<p>
There is a similar constraint on <code>a-&gt;m</code>.
</p>

<p>
There is no support for rvalue references, nor do I believe their should
be.  Again, opinions may vary but either this table or the definition of
<code>move_iterator</code> need updating.
</p>

<p>
Note: this requirement probably need updating anyway if we wish to
support proxy iterators but I am waiting to see a new working paper
before filing that issue.
</p>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote><p>
Move to Open. Howard to put his rationale mentioned above into the issue
as a note.
</p></blockquote>

<p><i>[
2009-10-26 Howard adds:
]</i></p>


<blockquote>
<p>
<code>vector::insert(pos, iter, iter)</code> is significantly more effcient when
<code>iter</code> is a random access iterator, as compared to when it is an
input iterator.
</p>

<p>
When <code>iter</code> is an input iterator, the best algorithm
is to append the inserted range to the end of the <code>vector</code> using
<code>push_back</code>.  This may involve several reallocations before the input
range is exhausted.  After the append, then one can use <code>std::rotate</code>
to place the inserted range into the correct position in the vector.
</p>

<p>
But when <code>iter</code> is a random access iterator, the best algorithm
is to first compute the size of the range to be inserted (<code>last - first</code>),
do a buffer reallocation if necessary, scoot existing elements in the <code>vector</code>
down to make the "hole", and then insert the new elements directly to their correct
place.
</p>

<blockquote><p><b>
The insert-with-random-access-iterators algorithm is considerably more efficient
than the insert-with-input-iterators algorithm
</b></p></blockquote>

<p>
Now consider:
</p>

<blockquote><pre>
vector&lt;A&gt; v;
<span style="color:#C80000">//  ... build up a large vector of A ...</span>
vector&lt;A&gt; temp;
<span style="color:#C80000">//  ... build up a large temporary vector of A to later be inserted ...</span>
typedef move_iterator&lt;vector&lt;A&gt;::iterator&gt; MI;
<span style="color:#C80000">//  Now insert the temporary elements:</span>
v.insert(v.begin() + N, MI(temp.begin()), MI(temp.end()));
</pre></blockquote>

<p>
A major motivation for using <code>move_iterator</code> in the above example is the
expectation that <code>A</code> is cheap to move but expensive to copy.  I.e. the
customer is looking for <em>high performance</em>.  If we allow <code>vector::insert</code>
to subtract two <code>MI</code>'s to get the distance between them, the customer enjoys
substantially better performance, compared to if we say that <code>vector::insert</code>
can not subtract two <code>MI</code>'s.
</p>

<p>
I can find no rationale for not giving this performance boost to our customers.
Therefore I am strongly against restricting <code>move_iterator</code> to the
<code>input_iterator_tag</code> category.
</p>

<p>
I believe that the requirement that forward
iterators have a dereference that returns an lvalue reference to cause unacceptable
pessimization.  For example <code>vector&lt;bool&gt;::iterator</code> also does not return
a <code>bool&amp;</code> on dereference.  Yet I am not aware of a single vendor that
is willing to ship <code>vector&lt;bool&gt;::iterator</code> as an input iterator.
Everyone classifies it as a random access iterator.  Not only does this not
cause any problems, it prevents significant performance problems.
</p>

</blockquote>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
Class template move_iterator 24.5.4.2 <a href="https://wg21.link/move.iterator">[move.iterator]</a>
</p>

<blockquote><pre>
namespace std {
template &lt;class Iterator&gt;
class move_iterator {
public:
 ...
 typedef <del>typename iterator_traits&lt;Iterator&gt;::iterator_category</del> <ins>input_iterator_tag</ins> iterator_category;
</pre></blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to <del>NAD Editorial</del><ins>Resolved</ins>. Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
</p>


<p id="res-1211"><b>Proposed resolution:</b></p>
<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a>.
</p>





</body>
</html>
