Re: equivalent of realloc in C++
Hendrik Schober wrote:
Andrei Alexandrescu wrote:
Hendrik Schober wrote:
Stephen Howe wrote:
And vector could be a lot smarter. It could work a lot harder before
deciding there is no choice but to allocate, copy and delete.
But isn't the above pretty much what 'std::vector' already does
(although it does so on another level than the heap)?
No. Because there is no proper interface on the allocator.
I'm not talking about the allocator, I'm talking about
'std::vector' itself. It will allocate more memory than
necessary so it can grow when you add a few values. If
there isn't enough room left, it reallocates and copies.
Doesn't this seems pretty similar to what 'realloc()'
does? And would 'realloc' really bring so much more than
just another layer doing the same?
No, realloc does something else. It can expand a memory block beyond
what was previously reserved for it.
By "previously reserved" you mean through a call to 'reserve()'?
because, if so, 'std::vector' can so, too. I don't need to call
'reserve()' very often, yet 'std::vector' mostly resizes without
doing allocate/copy/delete.
I didn't mean through a call to reserve.
My point: For most users and most cases 'std::vector' really _is_
the drop-in replacement for managing memory using 'malloc()',
'realloc()', and 'free()'.
Sure. Would be great, however, if that were the case for the more
demanding applications too if it didn't impede simpler uses.
If 'std::vector' could itself take advantage of 'realloc()' and
thus would perform better, than this is something that, for most
users and for most cases, belongs to 'std::vector's internals.
I see (but maybe I'm being naive here) that this might need some
addition to the allocator machinery in order to enable containers
to realloc. But again, most user in most cases have no need to
deal with allocators.
What users deal with is 'std::vector' using it's default allocator.
If changes to the allocator's interface would enable a performance
boost, fine. But IMO they won't (and shouldn't) change their code
for this. 'std::vector' would still be the perfect tool to deal
with situations where the number of objects of an array changes at
run-time.
Sure. This is a good point, but is not related to the discussion. The
discussion is about operator new being inferior to malloc, not about
vector in relationship to malloc. Vector does what it can using the
allocator interface.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]