Re: equivalent of realloc in C++
Boris Rasin wrote:
On Mar 17, 12:06 am, "Bo Persson" <b...@gmb.dk> wrote:
The premise was that we (1) do not have enough room to grow by 50%,
but (2) it just so happened that there were some spare bytes after
the current allocation that were enough for out immediate needs.
My solution was to fix (1) by enlarging the address space, so that
case (2) will never be needed. Thus we don't need extra code to
test for this highly unlikely case.
Have you seen a graphical representation of how general allocation
heap of a fairy complex application looks after it's been running
for a while? With every used block represented by black pixel and
every free block by white, the image looks like a white noise.
Probably every second allocated block in there has some free space
behind it. In-place reallocation would save a lot of copying and
would be a very common case, not the "highly unlikely case" you are
presenting it to be.
Yes, when you repeatedly try to squeeze 4 GB out of a 4 GB address
space, it probably becomes very fragmented. If you instead try to
allocate your 4 GB out of 16M TB, there will be a lot of white space.
We don't have to look for every last pixel in the graph.
If it violates the "You don't pay for what you don't use"- principle,
I don't want this byte-squeezing designed into the container/allocator
interface. I believe we would regret this later.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]