[gclist] C++ realloc semantics with garbage collection.

[Hans Boehm]

On May 29, 12:33pm, Jim Larson wrote:

> realloc() is hardly a mistake.  How else would you propose to grow or
> shrink a region of manually-managed memory?  If there are additional
> pointers into the region then the programmer has always had to supply
> some fix-up code.
>

You can clearly grow or shrink a region of memory (in the same sense as
realloc) by allocating a new chunk, copying its contents, and then deallocating
the old one.

One reason that realloc may have been a mistake even in C is that programmers
seem to assume that realloc does something fundamentally different from the
above.  For some otherwise very desirable malloc implementations it can't
behave much differently.  As a result, I suspect there's a lot of C code around
that greatly overuses realloc, because it was somehow assumed to be cheap.
 (The most common example is adding characters to the end of a dynamically
allocated string by calling realloc for each character.  That performs almost
acceptably in some cases, but there's no reason to expect that.)

If you view realloc as a minor performance hack to optimize a common sequence
of operations, then it's a useful feature.  If too many people view it as an
essential part of the language, then I agree with Charles that it's a mistake.

-- 
Hans-Juergen Boehm
boehm@mti.sgi.com