Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!icdoc!citycs!ba124
From: ba124@citycs.UUCP (K.A.Streater)
Newsgroups: comp.lang.c++
Subject: Re: realloc equivalent in C++
Summary: My idea was to get away from malloc/realloc
Message-ID: <84@citycs.UUCP>
Date: 24 May 89 21:13:05 GMT
References: <80@citycs.UUCP> <6590130@hplsla.HP.COM>
Organization: Computer Science, City University, London
Lines: 35

In article <6590130@hplsla.HP.COM>, jima@hplsla.HP.COM (Jim Adcock) writes:
> Good question.  I suspect the answer, in part, is going
> to lie in the implementation of a particular C++ compiler's
> implementation of new and delete -- which I haven't yet
> seen documented on any compilers.  Why not just continue
> to use malloc/realloc?  If you just need a chunk of memory
> you should be able to continue to use these as always.
> 
> If you actually need this feature for object creation and
> destruction, then presumably you need the capability
> rumored for future release in C++ compilers -- the ability
> to take over allocation/deallocation for a particular class
> by overloading new/delete.

The idea I first put forward was to get away from malloc/realloc.
The Zortech C++ uses malloc & free to implement new and delete
so why not add a new operator e.g. extend which will take an
object which has been new'ed and extend it.
i.e.
class array;		// previously implemented

	array* fred = new array[10];
	...
	fred = extend fred array[100];

which would copy the old contents of fred and add another 90 objects.

Does this sound too far away from the C++ ideals ????

Finally, I thought you could overload new/delete anyway.
-- 
K.A.Streater,				 JANET:		ba124@uk.ac.city.cs
UUCP:		ba124@citycs.UUCP	 ARPA:		ba124@cs.city.ac.uk
"There was a point to this story, but it has temporarily escaped the
Chronicler's mind.", Hitch-Hiker's Guide Part IV.