Boost logo

Boost :

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

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

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


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?


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