Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!umich!sharkey!bnlux0!bnlux0.bnl.gov!hoff
From: hoff@bnlux0.bnl.gov (Lawrence T. Hoff)
Newsgroups: comp.lang.c++
Subject: Why no renew
Message-ID: <2488@bnlux0.bnl.gov>
Date: 7 Feb 91 16:05:36 GMT
Sender: hoff@bnlux0.bnl.gov
Organization: Brookhave National Lab, Upton, NY
Lines: 34


    I haven't seen this question posted before, but I've only just started
reading this newsgroup, I apologize in advance if it is a FAQ.

    When I am coding an algorithm which requires dynamic memory allocation,
but the total memory requirements are not known in advance, I use
realloc(), rather than malloc()/copy/free(), because realloc is generally
more efficient in that data is only copied if necessary, i.e. is sufficient
contiguous memory in unavailable. As posted many times here recently, 
new should always be used with delete, and malloc/realloc should always
be used with free. One should not mix these allocation schemes. 

    My question is : Is there a 'renew' operator, i.e. a function which
acts like realloc, but works with memory allocated with the new operator?
If not, why not? 

    Some caveats come to mind, mostly they seem to follow the same theme : 
This (renew) is potentially dangerous, one would have to exercise extreme 
caution. However, this seems no more dangerous than realloc(), especially when
when dealing with intrinsic data types rather than arrays of class objects.
When dealing with arrays of class objects, there is of course the question
of how to do the copy (bitwise copy, assignment, or destroy/contruct), 
otherwise I can't see any fundamental reason this would not be possible 
to implement, with the caveat that whatever copy scheme was used might
not work with certain class objects.

    Of course, I can accomplish what I want to do with a new/copy/delete
operation, chossing the most approprite copy scheme for the data type in
question, but why sacrifice efficiency when it's not necessary. I WILL 
concede that one should perhaps not be concerned with efficiencies to any
great extent when one is dealing with dynamically allocated memory,
however this IS exactly why realloc() exists.

    Comments?