quote:Original post by Anonymous Poster
Anyway, I wouldn't worry about fragmentation. Realloc can't do anything more than what the library can do with a delete and a successive new. In fact, realloc needs to preserve the block contents, which may be a bit of a disadvantage (and certainly causes an unnecessary copy if you want to re-write the block).
quote:Original post by jeeky
In any event, "expanding" you array size does result in creation of a new larger buffer and copying the contents of the old one over, no matter what.
If there was no benefit of realloc over a malloc() and memcpy(), realloc wouldn't exist. In fact - try implementing your own malloc sometime, it's a really good exercise for insight into how memory management really works. Unix systems provide the sbrk() system call which is used to implement malloc. You'll see that it's quite possible to increase the size of allocated blocks.
The easiest way to find out is to confirm it yourself.
int *a = malloc(4);int *b = realloc(a, 8);return a == b;
The "new" block has the same adress as the "old" block. Also, you shouldn't be doing this kind of stuff at all if you didn't want to keep the contents of the memory.
As such, realloc is potentially enormously more efficient than new/copy/delete, since you don't need to run a few thousand constructors/assignment operators to shift memory around.
/Stary
[edited by - Stary on September 1, 2003 8:56:52 AM]