title: Is it fair to always recommend std::vector over realloc?
body: <p>From <a href="http://www.stroustrup.com/bs_faq2.html#realloc" rel="noreferrer">Bjarne Stroustrup's FAQ</a>:</p>
  
  <blockquote>
    <p>If you feel the need for realloc() - and many do - then consider using
    a standard library vector.</p>
  </blockquote>
  
  <p>I'll preface my question by agreeing that <code>std::vector</code> is better for many reasons, and I personally would always choose to use it over writing my own dynamic arrays with C memory allocation.</p>
  
  <p><em>But</em>, <code>std::vector</code> fragments memory as it grows because C++ has no equivalent of <code>realloc</code> (<strong>edit</strong> To clarify, I know that <code>std::vector</code>'s storage is contiguous and won't get fragmented, I mean fragmentation of the memory space caused by allocating and deallocating, which <code>realloc</code> can avoid by extending an existing allocation). So is it fair to always recommend it over <code>realloc</code>? With great care, couldn't you write something that works just like <code>std::vector</code> but using C allocation functions, which has the possibility to grow its memory without moving its address and copying existing elements, making it as good or better in terms of fragmentation and performance?</p>
  
  <p>And relatedly (bonus question!), <em>why</em> doesn't C++ have an equivalent to <code>realloc</code>? It seems like an odd thing to omit in a language that is so focused on performance. The section in Bjarne's FAQ has exactly that title (minus emphasis), but the answer doesn't address the 'why'. Was it just an accidental omission? Is there some fundamental incompatibility with how <code>new</code>/<code>delete</code> work? Does it not really give the benefits it seems to in practice?</p>
  
  <p><strong>Edit</strong>: ok, so I had neglected to consider the C nastiness of <code>realloc</code> - <code>std::vector</code> can't be rewritten using <code>realloc</code> because it only works with PODs, doesn't throw and so on. Perhaps a POD-only container written to deal with the nastiness would be a good idea for some situations. In any case though, the more interesting question becomes: would <code>std::vector</code> benefit from a C++ equivalent of <code>realloc</code>, which has (more or less) been answered here:</p>
  
  <p><a href="https://stackoverflow.com/questions/8003233/does-stdvector-have-to-move-objects-when-growing-capacity-or-can-allocator?lq=1">Does std::vector *have* to move objects when growing capacity? Or, can allocators &quot;reallocate&quot;?</a></p>
  
  <p>Sadly, the answer seems to be "yes, but the standards committee didn't vote it in". Here's hoping.</p>