Re: Looking for an open source memory pool
On Jul 28, 3:51 am, graham.keelli...@gmail.com wrote:
On Jul 26, 5:10 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
Since it's an embedded application it is never meant to
terminate; it is supposed to run "forever".
My definition of leak (ymmv) is when a process allocates
memory which no process ever frees.
Even if it only does it once, on start-up? By this definition,
I've never seen a C++ program which didn't leak.
The buffers used by cin, cout and cerr are never freed. Many
implementations of the STL also leak by this definition. With
older versions of Sun CC (I've not checked recently), array new
leaked.
I hope to test for this at unit test, s/w integration and
system verification test - so, yes, my memory pool should help
me test for leaks (even if I have to add a helper process to
scan the pool when the system is otherwise idle).
I don't use a memory pool for this, but a replacement operator
new/operator delete (which of course supposes that all
allocations are done with new and delete, and not malloc and
free). From experience with using it, with a number of
different implementations of C++ and its libraries, I've found
that 1) you have to wait until after start up to turn it on,
2) you may need to artificially exercise some components before
turning it on (e.g. create a couple of vectors of string, with
strings of various lengths in them), and 3) have some way of
temporarily turning it off.
When testing has found all(!) memory leaks, then garbage
collection is obviously useful. So, they are not mutually
elusive, although they are likely to be used at different
times.
Now, back to the practical... Does anyone know of a decent
memory pool in C/C++ ? The best which I have found so far is
Boost++ which I propose to extend. I just wondered if there is
another which is more suited to my porpoises.
It depends on what level you're looking for. I use the Boehm
collector a lot, both for garbage collection and leak detection.
I use my own debugging operator new/operator delete, not just
for leak detection, but for simulating out of memory situations,
ensuring that dangling pointers don't accidentally work, etc.
(My debugging operators are available at my site:
http://kanze.james.neuf.fr/code-en.html; they're part of the
Test component, but you'll need the Port component as well if
you want to compile them---unlike some other components, the
memory checking component depends very heavily on some of the
code in Port. For the Boehm collector, see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34