Re: Looking for an open source memory pool
On Jul 26, 12:14 am, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-07-25 17:10:38 -0400, James Kanze <james.ka...@gmail.com> said:
On Jul 25, 5:03 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-07-25 10:02:43 -0400, Juha Nieminen <nos...@thanks.invalid> sa=
id:
graham.keelli...@gmail.com wrote:
Something with garbage collection/defragmentation would be nice.
Aren't those two things a bit mutually exclusive?
No. When the application terminates, all reachable memory has
been leaked.
We must have a different definition of memory leaks. When I
terminate an application program, the system recovers all of the
memory, so no memory leaks.
Nevertheless, the program leaked memory, leaving it for the OS
to clean up.
Again, it depends on your definition of leaked. As a pragmatic
developer, the only definition which interests me is the one
that concerns me: the program hasn't "freed" memory that it
doesn't need anymore. If a garbage collector is present, and
could collect the memory, it isn't "leaked" (since the
application could reuse it). If its a one time operation, for
example constructing a singleton which is never deleted, it
isn't leaked (any more than a static variable is a "leak"). If
the application keeps memory that it doesn't need any more, even
if it does have a pointer to it, and could reach it (e.g. it's
in a map, indexed by a key that has been retired, and won't be
used any more), it's been leaked.
I rather insist on this definition, because people use all sort
of useless definitions, to prove that you can't have a memory
leak in Java (although Sun has had a couple in their bug list),
or some other claim that is only true because the definition is
useless.
(Of course, even this definition leaves some questions open. A
simple compiler will parse all of the source first, then
generate code. Once the source is parsed, no more error
messages will appear. Has it leaked memory because the buffer
of std::cerr hasn't been freed? It's not going to use it any
more.)
--
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