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).