I have been studying Stephen Cleary's boost::pool template and its subclasses with respect to using them for non-array based allocations in our company's product. We don't use many arrays that we need to dynamically allocate or resize except at init time. But we use lots of map-like collections and shared_ptr-like objects. Our use case is allocation of memory for individual objects varying in size from tiny (8 bytes, the case of a minimal impl similar to shared_ptr) to not so tiny (150-250 bytes, the case of comprehensive state tracking of an individual TCP/IP flow). In several cases, the count of allocated objects can be in the 100,000-1,000,000 range. Two items I've been thinking about: 1) The Guaranteeing Alignment doc's "convoluted example where the requested_size is 7, sizeof(void *) == 3, and sizeof(size_type) == 5" caught my attention. The lcm approach yields 105 bytes per chunk "wasting" 98 bytes per chunk, or 93% of the alloc. This was not so offensive in that it doesn't represent a practical use case of significance. But then, I considered a more common use case in which the consumer's object only had a char[13] data member against an lcm(sizeof(size_type), sizeof(void*)) == 4. The char[13] comes from the semantics of the consumer's app. Here, the lcm method would be to alloc a chunk size of 52; and better would be a chunk size of 16. As a practical matter, what regressions would be introduced if the requested size were just increased to the next multiple of lcm(sizeof(size_type), sizeof(void*))? I get the theoretical issue of the next chunk not being on a multiple of 13; but I can't think of a practical case where this would matter. 2) The issue of the array allocation performance at O(free store size) has me wondering whether the pool class should incorporate the "ordered free list" semantics at all. Maybe a separate class that uses a model more like the Linux kernel model would be better (i.e., a tiering of pages, page pairs, pairs of page pairs, etc.). With allocated chunk counts in the 10e5 - 10e6 range; use of the pool classes array semantics could get nasty. Just my two cents worth. BTW, I totally enjoyed studying Mr. Cleary's work; he, like most of the boost contributor's is lot's smarter than me. That's why, when we are working on building our catherdrals in app land, it's great to have a resource like boost to check on the quality of our bricks. Thanks to all. Regards, Mark -- Mark Deric Director, Research and Development Deepnines, Inc. http://www.deepnines.com