There is a long standing bug against Boost.Pool that points out that it allocates far too much memory when the size of the requested block is oddly sized: https://svn.boost.org/trac/boost/ticket/1252 For example if you request blocks of size 1501 bytes then you actually get 6004 byte sized blocks because Pool uses LCM to calculate a size that can store both a pointer and the requested block. There's some dispute on the Trac ticket whether the correct solution is to just round up the block size to a multiple of the pointer size. I'd like to run my take on this past you all and check I have the right fix ;-) ! So here goes - if we round up to the nearest multiple of pointer-alignment-size then: 1) The actual alignment requirements of the block (which only the client of Boost.Pool knows) must be a factor of the block size (otherwise arrays of blocks would be incorrectly aligned). 2) If the requested block has an alignment requirement >= pointer type, then of necessity alignment_of<void*>::value will be a factor of the block size and no rounding occurs or is necessary. 3) If the requested block has an alignment requirement < pointer type, then we may round up the block size, but this will only *increase* the alignment of the returned blocks so is always safe. Note that (2) assumes that all alignments are powers of 2, if that isn't true, then all bets are off. But I'm assuming there are no real-world architectures that violate that assumption? Thanks in advance, John.