Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)

[Joe Pfeiffer <pfeiffer cs nmsu edu>]

   >Having memory leaks has nothing to do with memory
   >fragmentation. 

   i think here you are wrong, is in fact one the subtle memory leak because
   any time you alloc/free the heap there a little but not negligeable memory leak
   pending on memory paging and how memory allocator lists manage this work.
   I can be more precise having a deeper look to kernel docs, i'm sure applies to
   dos/win kernel but should be the same on Linux.

If malloc/free causes a leak, then there is a bug in the memory
allocation/deallocation code.  If you're referring to the space
required to maintain free lists, that's not a leak, it's overhead.
This is a subtle distinction, but an important one:  a leak is gone
forever (or at least the lifetime of the process), while overhead can
be recovered if blocks can be coalesced.

The paging is completely irrelevant to the allocator, except in that
the allocator may be tuned to try to avoid crossing page boundaries --
but that has nothing to do with leaks, either.

I wouldn't be at all surprised to learn that Windows has memory leaks
in its allocator.  Having read the Gnu allocator, I sure didn't see
any leaks in it.

   >Speaking of which, this excerpt from VDK's 
   >documentation made me jump :
   >
   >            2. No memory freeing and/or deleting is requested, all new'ed objects will be automatically
   >            destroyed at application termination (in future releases an interleaved garbage collection
   >            will be provided).
   >

   jump why ? don't believe or never seen?

I can't speak for the original poster, but in my case this sounds like
you're building in a huge leak, and promising to plug it with garbage
collection some time in the future.
-- 
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer