AMDG Ben Muzal wrote:
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.)
You're missing the point of boost::object_pool.
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.
This feature has to stay because it is the the reason object_pool exists as a separate class.
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?
I do consider it a bug, although this isn't really the intended usage of object_pool. In Christ, Steven Watanabe