Destroying single objects that were created from an object_pool uses ordered_free, as you discovered. An object_pool will keep its free list ordered, so that it can run through the "list of allocated objects" in O(N) time instead of O(N**2) time in ~object_pool. It's a performance tradeoff with object_pool::destroy; object_pool was designed more for a "allocate a bunch of objects and then destroy all of them" type of scenario.
-Steve
thanks.
if i only construct one and destroy exactly.
is the order_xxx not need now? and (maybe?) i don't care the performance
in ~object_pool.
i use pool to avoid mem-piece.
so i implement a simple ObjectPool (see below).
i think random construct and destroy is fast now.
is right?
#include