Re: equivalent of realloc in C++

Andrei Alexandrescu wrote:


But most code shouldn't use operator new (directly) anyway.
Call me stubborn, but as a second job I have been teaching
C++ in the last decade and if there's one thing I've learned
it's that most users shouldn't fiddle with memory manually.
They shouldn't even be using the new and delete operators
(or 'malloc()'/'free()', FTM) directly, let alone try to
make use of an advanced feature that expands memory in place.
For most users, new should be used for allocating single
objects exclusively, everything else should be done using a
container. (And for single objects operator new is vastly
superior to 'malloc()' as it relieves users from having to
remember to initialize the raw memory handed out by the heap
manager.)
So what we're talking here is only cases where the memory
for many objects lying side-by-side needs to be expanded to
add more objects at the end. That's dynamic resizeable arrays
and most users should use 'std::vector' for that task. I fail
to see how new/malloc comes into the picture here.
So instead let's look at how to allow 'std::vector' to make
use of the heap manager's built-in ability to grow a chunk of
memory. If an obscure and rarely understood extension to the
allocator interface allows this, then that's all what's
needed:
  size_type allocator::resize(const_pointer p, size_type new_requested);
Most users won't even bother with it, most user's code will
become more efficient without them touching a single line of
it, and people like those discussing this here have a more
sophisticated hammer at their hand to be used with their own
special-purpose nails^Wcontainers.
Now, whether this is implemented using some system-specific
extension of the heap manager or whether your define some
publicly available memory resize function doesn't make all
that much difference -- as long that, if you decide for the
latter, it's even more obscure than the allocator member from
above, so that most users will never try to make use of it
directly. (Well, thinking about this, it indeed _does_ make a
difference. I'd rather it's some obscure, hidden, hard-to-use,
and non-portable vendor-specific quirk as that reduces the
number of unfit users trying to use it...)