title: What's the benefit of std::back_inserter over std::inserter?
body: <p>As far as I can tell, anywhere <code>std::back_inserter</code> works in an STL algorithm, you could pass an <code>std::inserter</code> constructed with <code>.end()</code> instead:</p>
  
  <pre><code>std::copy(l.begin(), l.end(), std::back_inserter(dest_list));
  std::copy(l.begin(), l.end(), std::inserter(dest_list, dest_list.end()));
  </code></pre>
  
  <p>AND, unlike <code>back_inserter</code>, as far as I can tell <code>inserter</code> works for ANY STL container!! I tried it successfully for <code>std::vector</code>, <code>std::list</code>, <code>std::map</code>, <code>std::unordered_map</code> before coming here surprised.</p>
  
  <p>I thought that maybe it's because <code>push_back</code> could be faster for some structures than <code>insert(.end())</code>, but I'm not sure...</p>
  
  <p>That doesn't seem to be the case for <code>std::list</code> (makes sense):</p>
  
  <pre><code>// Copying 10,000,000 element-list with std::copy. Did it twice w/ switched order just in case that matters.
  Profiling complete (884.666 millis total run-time): inserter(.end())
  Profiling complete (643.798 millis total run-time): back_inserter
  Profiling complete (644.060 millis total run-time): back_inserter
  Profiling complete (623.151 millis total run-time): inserter(.end())
  </code></pre>
  
  <p>But it does slightly for <code>std::vector</code>, though I'm not really sure why?:</p>
  
  <pre><code>// Copying 10,000,000 element-vector with std::copy.
  Profiling complete (985.754 millis total run-time): inserter(.end())
  Profiling complete (746.819 millis total run-time): back_inserter
  Profiling complete (745.476 millis total run-time): back_inserter
  Profiling complete (739.774 millis total run-time): inserter(.end())
  </code></pre>
  
  <p>I guess in a vector there is slightly more overhead figuring out where the iterator is and then putting an element there vs just arr[count++]. Maybe it's that?</p>
  
  <p>But still, is that the main reason?</p>
  
  <p>My followup question, I guess, is "Is it okay to write <code>std::inserter(container, container.end())</code> for a templated function and expect it to work for (almost) any STL container?"</p>
  
  <hr>
  
  <p>I updated the numbers after moving to a standard compiler. Here is my compiler's details:
  <br>gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) <br>
  Target: x86_64-linux-gnu</p>
  
  <p>My build command:</p>
  
  <pre><code>g++ -O0 -std=c++11 algo_test.cc
  </code></pre>
  
  <hr>
  
  <p>I think <a href="https://stackoverflow.com/q/23360656/751061">this question asks the second half of my question</a>, namely, "Can I write a templated function that uses <code>std::inserter(container, container.end())</code> and expect it to work for almost every container?"</p>
  
  <p>The answer there was "Yes, for every container except for <code>std::forward_list</code>." But based on the discussion in the comments below and in <a href="https://stackoverflow.com/users/2746253/user2746253">user2746253</a>'s answer, it sounds like I should be aware that this would be slower for <code>std::vector</code> than using <code>std::back_inserter</code>...</p>
  
  <p>Therefore, I might want to specialize my template for containers using <code>RandomAccessIterator</code>s to use <code>back_inserter</code> instead. Does that make sense? Thanks.</p>