Like I said, if you want the destructors called when the pool is destroyed, you should be using a container not a pool. (allocators are not containers. containers delete the objects they hold because they own them. Allocators however do not own the objects that they allocate.) But that is not really the point of my post. That 'feature' of the destructor will have to stay so that it does not break any existing code. My real problem is the O(n^2) nature of allocating then dealocating N objects. Am I wrong that the O(n^2) behavior should be considered a BUG? --Ben On Mon, Mar 16, 2009 at 1:58 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Ben Muzal wrote:
However, my personal feelings about a pool is that the pool should not be calling the destructors on any objects that are still allocated when the pool is destroyed.
If that's what you want, then use boost::pool instead of boost::object_pool.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost