title: Right way to "reserve or shrink" a vector to a known future capacity need
body: <p>I've written countless software modules around the common theme of a long lived vector that some times (at unspecified frequency) must have its content updated.</p>
  
  <p>Idiomatic implementation:</p>
  
  <pre><code>void LongLived::reconfigure(const InputT&amp; whatever_input)
  {
      m_vector.clear();
  
      m_vector.reserve(whatever_input.size());
  
      populate(m_vector, whatever_input);
  }
  </code></pre>
  
  <p>Notice that the idiomatic implementation will <em>never</em> reduce the capacity of its internal buffer. What if this is not ok? Just use <code>shrink_to_fit()</code>, I thought:</p>
  
  <pre><code>void LongLived::reconfigure(const InputT&amp; whatever_input)
  {
      m_vector.clear();
  
      m_vector.reserve(whatever_input.size());
      m_vector.shrink_to_fit(whatever_input.size()); // ← Here
  
      populate(m_vector, whatever_input);
  }
  </code></pre>
  
  <p>Oh, how nice that would be… But to my surprise, it doesn't compile, because <code>shrink_to_fit()</code> doesn't take a number!</p>
  
  <p>The way <code>shrink_to_fit()</code> is supposed to be used, apparently, is that you fill the vector first. Then, you call <code>shrink_to_fit()</code>, which is going to derive the capacity need from the number of elements in the vector after the fact, but that is clearly suboptimal if I could have told it that beforehand, because now, all that content has to be moved.</p>
  
  <p>Objective: I would like a function <code>vector_reserve_or_shrink()</code> to be used in this context:</p>
  
  <pre><code>void LongLived::reconfigure(const InputT&amp; whatever_input)
  {
      m_vector.clear();
  
      vector_reserve_or_shrink(m_vector, whatever_input.size()); // ← Implement this!
  
      populate(m_vector, whatever_input);
  }
  </code></pre>
  
  <p>I'm not actually obsessed with shaving every unused byte off the vector. Rather, I would be glad to leave it up to something implementation defined like <code>shrink_to_fit()</code>, which might know something about the quirks of the allocator, and may choose to do nothing. This way, one doesn't risk making an <a href="https://en.wikipedia.org/wiki/Abstraction_inversion" rel="noreferrer">abstraction inversion</a> that negates any lower level optimizations. For example, say the allocator's granularity is 16: Then, the vector implementation might like to give you 15 bytes for free when you ask for one, for all I know, which would just be counterproductive to try to give back.</p>