So, I see likewise that 20 is the number per uint...I guess I missed it earlier. So, once I determine that I guess I can safely use 20? Another question: If I don't release but the set is destroyed then that pool's memory will get re-used if I create another set? I assume yes, but confirming. A comment: I strongly encourage whoever keeps up the documentation put in some additional notes about this behavior, and update the author's contact e-mail. It is difficult when it is new and one already has one's own code to deal with...e.g. while trying to figure this out I had another issue with MSVS 2008 not showing local variables in the debugger under Windows 7 64-bit. The VS issue only reared it's ugly head in my pool_alloc test program. And running into multiple issues at once is typical in my experience. On Thu, Mar 18, 2010 at 3:23 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
B Hart wrote:
nope, continued upwards and release_memory() always returns false.
I stepped though
#include <boost/pool/pool_alloc.hpp> #include <set>
int main() { { std::set<int, std::less<int>, boost::pool_allocator<int> > s; for(int i = 0; i < 100; ++i) { s.insert(i); } } boost::singleton_pool<boost::pool_allocator_tag, 20>::release_memory(); }
and the call to release memory does seem to work.
Also, I would say that release_memory is broken, or needing revision, if one has to guess what the pool size is.
It isn't broken. release_memory works fine if you can find the right pool. Because std::set does not expose the type that it actually allocates there is no portable way to do so.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users