In article <DOUGM.94Jan17230457@cs.cs.rice.edu> dougm@cs.cs.rice.edu (Doug Moore) writes:
|    Why isn't there a 'realloc' to go with new & delete ?
|
|Good question.  I'll get flamed for this, but I don't think there is a
|good reason for not having something like realloc compatible with new
|and delete.
....
|There was an article in the C++ Report two or three months ago (by
|Tony Hansen, I think) on an attempt to make a renew template.  You
|might find it interesting.

Koenig followed by Hansen's rebuttal in the C++ Report give excellent
background to this question.  However, I'll claim just the opposite
to your above assumption.  Namely that there is NO good reason for
something like realloc compatble with new and delete.  The reason
being is that the original C definition of malloc/realloc/free assumes
that ALL allocations must be reallocable, when in reality only a
tiny percentage ever are.  If you change the assumption to read
that SOME allocations must be reallocable, then the solution becomes
trivial:  Namely rather than trying to hack existing new/delete
implementations to add renew capabilities, leading to a new/renew/delete
triple analogous to malloc/realloc/free, instead one can implement
a renew/renew/renew triple that state that original allocation is
designed to be reallocable in the first place.  Such a triple can
be relatively easily implemented in terms of new/delete.  Since
only a small percentage of all allocations are ever resized, it
is reasonable to require the programmer to specify those allocations
that may be resized.  The standard new/delete can then remain optimized
for the common situation where the allocation will not be resized.

 size_t initsize, newsize;
...
 FOO* pfoo = renew((FOO*)0, initsize); // initial size
 FOO* pfoo2 = renew(pfoo, newsize); // resize
 renew(pfoo, 0);    // free

    Why isn't there a 'realloc' to go with new & delete ?

Good question.  I'll get flamed for this, but I don't think there is a
good reason for not having something like realloc compatible with new
and delete.

The gurus will say that there is no good definition for a "renew"
operator.  "When realloc would allocate new space and copy, what
should renew do?," they ask.  The array elements would have to move
from one place to another, and there's no guarantee that moving a C++
object doesn't violate a class invariant (what if, for example, an
object stores in a data field its own address?).  A simple language
extension could eliminate the problem of these non-relocatable
objects, and in practice they're quite rare anyway.  For almost every
case, copy-constructing into the new space and then destructing the
old space would work fine.

But those are the familiar arguments.

There's really a lot that could be done to improve heap management in
C++.  For example, we know that the number of objects in a vector is
stored somewhere, because that's how many destructor calls are needed
to unmake it.  But can we portably get at that number?  No.  So we
separately store the number and pass it to functions that need it.

Oh, well.

There was an article in the C++ Report two or three months ago (by
Tony Hansen, I think) on an attempt to make a renew template.  You
might find it interesting.

Doug Moore
(dougm@cs.rice.edu)

I've never posted to a std group, nor had cause to, but this has been bugging
me and would make a good addition to the std unless there is a reason not
to have it (instead of using malloc,realloc & free) :

 Why isn't there a 'realloc' to go with new & delete ?

It doesn't (shouldn't) *move* existing memory/objects about, but allow you to
grow (& new extra members) and shrink(& delete end members) in the array.

My (feable?) point is that otherwise I have to write my own ie:

  allocate big_array;
  for(members in array)
    {
    big_array[member]=old_array[member];
    }
  delete old_array;

ok, you can template this, but you still shove about all you objects, how
ineffecient (time/space) do you think this is for (say) 1024 element array of
large objects ?

This just seems like a *very* useful operation got left out of the original
language...

Can anyone clarify why ? (I'm sure Bjarne thought about it.....)

Thanxs, hope this hasn't wasted you time,

Dom De Vitto