The quick_allocator not-a-memory-leak

I've a class using the boost quick_allocator like this: class Chain{ //... void* operator new(std::size_t sz){ return boost::detail::quick_allocator<Chain>::alloc(sz); } void operator delete(void *p,std::size_t sz){ boost::detail::quick_allocator<Chain>::dealloc(p,sz); } //... }; I've started using valgrind ( http://valgrind.kde.org/ ) to look for memory problems in my unit tests and it is complaining that the memory is never released. Now I understand this: // "Listen to me carefully: there is no memory leak" // -- Scott Meyers, Eff C++ 2nd Ed Item 10 But is there some function I can call at the end of my program to: a) confirm I've called dealloc() for every alloc() and that the next pointer is currently at start b) release the memory. Valgrind supports suppressing the complaint but the check of deallocs matches allocs would be a useful test anyway. Darren

Darren Cook wrote:
I've a class using the boost quick_allocator like this:
class Chain{ //... void* operator new(std::size_t sz){ return boost::detail::quick_allocator<Chain>::alloc(sz); } void operator delete(void *p,std::size_t sz){ boost::detail::quick_allocator<Chain>::dealloc(p,sz); } //... };
I've started using valgrind ( http://valgrind.kde.org/ ) to look for memory problems in my unit tests and it is complaining that the memory is never released.
Now I understand this: // "Listen to me carefully: there is no memory leak" // -- Scott Meyers, Eff C++ 2nd Ed Item 10
But is there some function I can call at the end of my program to: a) confirm I've called dealloc() for every alloc() and that the next pointer is currently at start
No, sorry. This would require quick_allocator to keep too much debugging information. It is not a debugging tool. Use a different allocator in valgrind/test builds. This might be easier if I add something like BOOST_QA_USE_MALLOC to make quick_allocator just forward alloc/dealloc to malloc/free.
b) release the memory.
Again, no, since currently quick_allocator does not keep track of its allocations (because it doesn't need to). I'll think about this.

No, sorry. This would require quick_allocator to keep too much debugging information. It is not a debugging tool. Use a different allocator in valgrind/test builds.
Yes, that was the conclusion I came to (after looking at the quick_allocator code and working out what my patch would need to do to).
This might be easier if I add something like BOOST_QA_USE_MALLOC to make quick_allocator just forward alloc/dealloc to malloc/free.
I already had the blocks wrapped with USE_MEMORYPOOL_QUICK_BOOST (and the alternative memory pools I tried) so falling back on standard new/delete was easy enough. Thanks, Darren
participants (2)
-
Darren Cook
-
Peter Dimov