On Thu, Oct 18, 2012 at 8:15 AM, DUPUIS Etienne <e.dupuis@ateme.com> wrote:
If I understand correctly, your 'pool' manages live objects, i.e. objects that are currently in use by the application. I was rather working on a pool which manages memory for object allocation; i.e. as soon as an object is released back to the pool, it's content is destroyed and lost; hence there is no way to index elements released to the pool as we can think of them as if they no longer exists.
Currently it manage live boost::optional objects, which have constructed or not the object they wrap, which is the same to say it manage raw memory which have an object constructed or not, which is I believe exactly what you describe as a pool. So I need objects to have specific address (for fast access), not move in memory, and be destroyed when not used but the memory is still allocated and ready for another object to be created in. I also need to go through all the live objects for updates. Assuming I'm using a vector or stable_vector, it is faster to just go through all elements from begin to end and check if it's a live object, and if it is to update it. If I was using a boost::pool, I would be forced to have, say, a std::vector<T*> which would have contained only pointers to live objects and would have to be updated when objects are created or destroyed. As stable_vector provide iterators to go through all the elements, I don't need to do this at the moment. It's ok to me if a pool system don't have a way to go through all the objects, or a way to go through all the live objects. However I always have to setup such system at some points when I need a pool, most of the time by encapsulating the pool in a factory class that does the job. Joel Lamotte