title: Erase-remove idiom: what happens when remove return past-the-end-iterator?
body: <p>I got this question when I was reading <code>erase-remove idiom</code> (item 32) from Scott Meyers <a href="https://rads.stackoverflow.com/amzn/click/com/0201749629" rel="nofollow noreferrer" rel="nofollow noreferrer">"Effective STL”</a> book.</p>
  
  <pre><code>vector&lt;int&gt; v; 
  ...
  v.erase(remove(v.begin(), v.end(), 99), v.end());
  </code></pre>
  
  <p><code>remove</code> basically returns the "new logical end” and elements of the original range that start at the "new logical end" of the range and continue until the real end of the range are the elements to be erased from container.</p>
  
  <p>Sounds good. Now, let me ask my question:</p>
  
  <p>In the above example, <code>remove</code> can return <code>v.end()</code> if 99 is not found in the <code>vector v</code>. It is basically passing <code>past-the-end-iterator</code> to erase method.</p>
  
  <ol>
  <li>What happens when <code>past-the-end-iterator</code> is passed to the <code>erase</code> method?  Does standard says it a UB? </li>
  <li>If it is undefined behavior, then <code>erase-remove idiom</code> example in Scott Meyer’s book should have looked like:</li>
  </ol>
  
  <p></p>
  
  <pre><code>  vector&lt;int&gt; v; 
      ...
      vector&lt;int&gt;::iterator newEndIter = remove(v.begin(), v.end(), 99);
      if(newEndIter != v.end() )
      {
       v.erase(newEndIter, v.end();
      }  
  </code></pre>
  
  <p>Any ideas on this?</p>