On Tue, Oct 16, 2012 at 9:24 AM, DUPUIS Etienne <e.dupuis@ateme.com> wrote:
The pool2 I am designing will address all issues; I am not finished as I am currently trying to know what users need.
Hi, I just wanted to comment on this quickly. I'm making video games (and digital narration stuffs too). I don't make games always like in traditional industry, where both object pools and small allocation pools are used heavily (and arena too). I mostly use only object pools in my own project, for some game-specific state objects. Last week I finished implementing a template factory class (not really generic though) that have the following features: 1. it have a "pool" of objects, meaning it have to be stable (objects must not move in memory). 2. it provide a way to go through all the elements very fast 3. it provide an "index" by "id" of objects Basically this means I wanted a std::vector of elements, which should be reserved and would not go higher than a specific size, plus a map<id, element*> for the index (that is not interesting here). The problem was that I didn't want to limit the number of elements, to allow the same code to be usable by the in-game editor, meaning I cannot really fix a maximum of elements before having edited some "map" of the game. (maybe I'll fix later, but I don't want to for some reasons). Having done the same system before with boost::pool (from 1.44 version I think) and I was not happy with the performances, I didn't bother trying using it. So I implemented it first with std::vector and std::map, then I decided to try boost::stable_vector instead. It have some speed disavantages, but I made some tests and it appear that if you first resize (not reserve) the stable_vector, then it is very fast to go through the element, almost as fast as with a std::vector. (in my tests at least) Then I thought that, as I want objects to be created and destroy in an unpredictable order, a solution would be to make them optional Currently, my solution is implemented by using a boost::stable_vector< boost::optional<T>> which seems efficient (to my surprise). In particular it allows me to go through all elements in a fast way, not like the current pool. It also allows me to fully construct and destroy objects like in a pool instead of "reusing" them, like often done in other game companies, which don't involve constructor and destructor and is source of maintenance bugs. I don't know yet the drawbacks of using this combination compared to using a better pool implementation, so I just wanted to give this feedback see if there are some things you're working on for pool2 that would make things better. Hope it helps. Joel Lamotte