Re: malloc/free & new/delete balance

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> > How about listing some minimum requirement, like:
> > 
> > if an object is freed, and the next allocation is for an object of the
> > same size, that allocation will succeed.
> 
> That rule prevents the runtime from releasing memory to the operating
> system and also forces the runtime to use a different method to
> allocate memory for its internal use.

Well, to address the internal use problem, you could define a set of
operations that won't cause internal use, and only make a statement
what happens as long as only these operations are used.  I hope no
implementation woul need to internally allocate memory for a sucession
of calls to new / delete after such a call has been made before?

Forbidding to release memory to the operating system is a different
matter, though.
Maybe we can work around this problem by limiting the statement to situations
where the operating system exhibits the same behaviour for allocating/freeing
memory. (I.e. you can re-allocate what you have freed - that should be
the case when no other process allocates memory, or if allocation is
limited by a software per-process limit first.
Of course a silly operating system might not even guarantee re-allocation
even for a single process running and no I/O going on; but that would
be not object of the definition.

We'd only that that *if* / while the OS allows re-allocation, and
while the program performs only operations of a limited set that need
no dynamic internal storage growth in the runtime, then the program
can also perform re-allocation.