At 05:48 PM 10/8/2003, Fisk, Kevin wrote: >Is there any concept of reallocation to change the size of allocated memory >inside a pool. If there is no data past the end of the allocated memory in >the pool, it shouldn't require me to allocate a new buffer and transfer all of >the data to the new buffer. I also then would have to have a pool more than >double the size of the largest buffer I plan to extend.
Kevin, your request isn't unreasonable (in fact apr_psprintf() does just that) and we should extend this, externally. Note that it is quite unlikely to be useful if you have any APR calls using the same pool (or pool-based object in the same pool) while you are constructing your buffer object, or if you expect to resize-downwards the pool buffer. Note that pools are designed for objects to expand, and although they could conceivably compact, the idea of pools is never to be a dynamic grow/shrink schema. I think most developers would agree that using this facility internally to the library should have been a hint that it is greatly desired externally to apr. The benefit of pools is alloc once and forget. This is whey they have better performance than malloc/free. Bill
