pool

From: Stephen Cleary (shammah_at_[hidden])
Date: 2000-06-30 07:38:07

Another (IMO, important) update to pool!  Under pool/pool.zip

Changes since last time:
 . Tracing statements removed.  Instead, pool's can now dump their 
internal structure.
 . Size of blocks allocated from new[] is now a run-time value, which 
approximately doubles.
 . Contiguous allocation of multiple chunks supported.  This allows 
full support for vector<> and deque<>.
 . "trace.h" was removed.
 . "ct_gcd_lcm.h" was added.  This file just provides two compile-
time algorithms: gcd and lcm.
 . "mutex.h" was changed to (hopefully) auto-detect Win32 or POSIX.

I wanted to go ahead and post this now, in case anyone wanted to play 
with it.  This is the first "fully functional" version.  *Please 
note* that the comments before the classes are now out-of-date!  
That's the first thing on my TODO list, but I won't be able to do it 
for a few days. . .

And on the "to do soon" list:
 . Update the comments, move out into html files
 . Provide freeing of memory -- set_new_handler, etc.
 . Provide examples of using pool<> for class new/delete and global 
new/delete

--------------------

I have a few design questions (and would like opinions), relating to 
the consecutive (array) malloc/free functionality:

1) The "next size doubling" idiom.  Right now, I have pool's default 
"next size" value at 31, and, instead of doubling it each time, I 
double it and add one.  So the number of bytes requested in my calls 
to new[] are not 2**n chunks but 2**n - 1 chunks (each chunk is at 
least sizeof(void *)).  Is this OK, or should I go back to the more 
standard 2**n?

2) How should array requests influence "next size"?  Right now, I 
simply approx-double "next size" as above until it reaches the amount 
requested, and then split off any chunks of that block that aren't 
used by the array.  There are two alternatives I considered:
  a) For array requests (unless we already have them consecutively), 
just allocate exactly that many and don't worry about splitting up 
the block until it's freed.  Then it won't influence the standard 
"next size"-doubling idiom above.
  b) We can also round up the requested array size to 2**n chunks (or 
2**n - 1 chunks), and allocate that many and split off the block, but 
not save the rounded-up size, so it won't influence the idiom either.

Thoughts?  Opinions?

        -Steve