🚀 go-pugleaf

Hi,

Kerry Kimbrough (kk@onr.com) wrote:
: I gather from a recent message here that ANSI C++ (still) does not
: define the moral equivalent of realloc(). This has always seemed
: regrettable to me. I also find the rationale expressed in the 
: comp.lang.c++ FAQ to be completely unsatisfactory. Surely someone
: from this group can tell me why this omission is either a good thing
: or at least not a major obstacle for efficient implementation of 
: extensible arrays.

I can't see why it is a good thing (neither can I see why it is a bad
thing...) but I can tell you why it is no major obstacle: It is
possible to

  - allocate "raw" (i.e. uninitialized memory) with 'operator
    new(size_t)' or relatives. Correspondingly, it is possible to
    release "raw" memory (i.e. memory where the objects contained were
    destructed) using 'operator delete(void*)' or relatives.
  - construct an object in-place using 'operator new(size_t, void*)'
    (placement new).
  - destruct a specific object of type 'T' using an explicit destructor
    call ('~T()').

These are the major ingredients necessary for a 'realloc()' function.
The only missing aspect is the possibility, to make use of the
knowledge of the memory system about the size of the memory block
occupied of the array to be resized. This is unfortunate but a
specialized array class can even circumvent this problem by using a
specialized memory management facility. I think an extension of the
language in this direction is neither necessary nor suitable (and maybe
even impossible for some environments).

The basic operation of a 'realloc()' function increasing the size of an
array would be to

  - allocate raw memory
  - copy the elements from the orginal array using placement new
  - construct the remaining objects
  - destruct the elements in the original array
  - release the the original array as raw memory
  - return a pointer to the newly allocated array

(An implementation without error checking of the procedure is not much
longer than this description. See e.g. the article "How to 'renew' a
built-in array" in comp.lang.c++.moderated or my implementation of an
array class at
<http://www.informatik.uni-konstanz.de/~kuehl/c++/array.h.html>).

Although this procedure CANNOT be used for arrays allocated with 'new
T[size]' (e.g. because the implementation can place auxiliary data in
front of the array such that the address to be passed to 'operator
delete[]()' cannot be figured out) it CAN be used inside an array class
where the built-in array used for the representation is created like
the returned array in the 'realloc()' function (of course it is also
impossible to release such an array with 'delete[]...': It is also
necessary to do this by hand).

Note, that this implementation even provides some additional freedom: A
built-in version of 'realloc()' can only use the copy constructor to
initialize the new array. A "home-grown" version can use a "move
constructor", i.e. a constructor which transfers allocated resources to
the new array leaving the original objects in a state only valid for
destruction (destruction is exactly what happens next to the orginal
objects).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]