Boost logo

Boost :

Subject: Re: [boost] [pool2] Requests for comment
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-10-16 08:00:15

On Tue, Oct 16, 2012 at 9:24 AM, DUPUIS Etienne <e.dupuis_at_[hidden]> 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
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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at