Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2000-11-20 10:15:23

Currently, pool requires compile-time knowledge of the allocation size for
the high- and medium- level interfaces (pool_alloc and sized_pool).
Therefore, an application that must defer the pool allocation size [1] is
forced to use the low-level interface. To be clear, I am referring to a
situation where all elements of a pool are the same size (a fundamental
constraint); the issue is whether the size need be known at compilation time
versus at the time of construction of the pool.

I propose to create another medium-level interface that replaces the
RequestedSize template parameter with a constructor argument. My preferred
naming would be to call the proposed version sized_pool and the existing
version static_sized_pool.

The implementations of sized_pool and static_sized_pool would be similar,
except that sized_pool would require a member variable to hold the size.

[1] An example of such an application is a database engine I worked on
recently for use by one of my company's product lines. It is a small-scale
(all in-memory) general-purpose database and so doesn't know until run-time
(specifically table creation time) what the fixed-length portion of a given
record will be. However, once the table definition has been established, it
knows what the allocation size of all rows will be, a fact that pool can
leverage. (Just so no one thinks I'm crazy, there were good reasons for us
home-growing a database engine: it needed extensive fine-grained
notification capabilities and had to be really fast. It turned out to be a
real tribute to the standard library interface design that a general-purpose
database engine could use a std::multiset at its core and a tribute to
STLport that, even without pool optimization, the executable was as fast as
it was, about 10x faster than MS Jet via OLE DB, our yardstick).

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