Path: utzoo!attcan!uunet!lll-winken!uwm.edu!psuvax1!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Making operator new smarter
Summary: Not hard
Keywords: memory, new, malloc
Message-ID: <441@mole-end.UUCP>
Date: 18 Sep 90 05:50:06 GMT
References: <10564@life.ai.mit.edu>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 24

In article <10564@life.ai.mit.edu>, rpk@rice-chex.ai.mit.edu (Robert Krajewski) writes:
> Has anybody tried hacking operator new (size_t) to behave better
> with typical C++ usage ?  In particular, it seems that the constant
> copying and destruction of objects that have a new'ed part will
> tend to result in allocations requests for a piece of memory that
> is the same size as one that was just freed.

For class types, this isn't very hard at all.  It's a few days work to
write a pool allocator, write an interface that will allow a class type
to get access to a pool of memory chunks of the appropriate size, and get
it all running with almost arbitrary classes.  Here it's important that
the destructors be virtual so that you get the correct operator delete
called.

This has no doubt been done about a dozen, a gross, and a score times;
howzabout a version in a library?

As an aside, if you are on a Sun under SonOS4.x there are some calls you
can make to tell  malloc()  to use simple pools for memory requests of
size  N  or less.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile