[boost] Re: Challenge: pool allocator

From: Stephen Cleary (scleary_at_[hidden])
Date: 2000-03-03 12:19:27

dave abrahams wrote: 
> Steve wrote:
> 
> > BTW, what is the proposed purpose of 'pool'?  Just a garbage
collector?
> 
> 1. garbage collector
> 2. Saves on space overhead for dynamic allocation (size labels,
internal
>    fragmentation)
> 3. Should be faster than almost any variable-size allocator

OK.  Yes, pool should do all these.  It uses the obvious fixed-size
allocation algorithm that you find in *any* embedded OS, which is much
faster and has less memory overhead than generalized allocation
algorithms.

> I'm a little curious about the
> function-object-constructor approach. While perfectly general, it
seems a
> lot less convenient than the family-of-template-functions strategy.
Maybe it
> would be best if both were available.

I considered the family-of-template-functions -- by this I assume you
mean:
  template <typename A1>
  void construct(A1 & a1) { ... }
  template <typename A1, A2>
  void construct(A1 & a1, A2 & a2) { ... }
  ...

I chose not to approach the construction this way because it's limited;
that is, there's some limitation in the library code that requires
editing of that library code to extend.  Users, IMO, should not edit
library code.  Specifically, the number of variables that can be passed
to the constructor is limited.

There is another possibility: we could provide an "external" (in a
*.inc file) class that users could extend.  If we decide to go this
direction, I would recommend providing an m4 script that would generate
this file (m4 is on every Unix system and is EZ to install on M$), and
a little batch file/shell script that takes the parameter of "the
maximum nubmer of constructor parameters" and runs the script.

I'm currently working on a Function Object Generator library for
submission, and this is the technique I use to overcome similar
semantic constraints in C++.

       -Steve