Platform: Win32, VC 7 & VC 8.1. I have run into a problem using fast_pool_allocator across DLLs: it 'leaks' memory. In this example, DLL A: 1. declares a container type that uses fast_pool_allocator 2. provides a function to populate the container type DLL B creates instance(s) of the container type & calls DLL A to populate those instances. DLL A ----- struct S { /* A bunch of data */ }; typedef std::list container_of_s; /* Fills s with a number of S instances */ void dll_populate_container_of_s(container_of_s &s); DLL B ----- void fun_a() { for (int nLoop=0; nLoop<100; ++nLoop) { container_of_s sc; dll_populate_container_of_s(sc); /* manipulate sc in some way */ /* sc is destroyed, but memory is not returned to the pool it was allocated from */ } } The problem is that the memory allocated by fast_pool_allocator inside DLL A (by dll_populate_container_of_s) is not returned to the same pool it was allocated from. I've tracked this down to fast_pool_allocator being backed by a singleton. It turns out that each DLL get's it's own copy of that singleton. So the memory allocated by fast_pool_allocator<S> inside DLL A is returned to a different fast_pool_allocator<S> inside DLL B. Technically not a leak, but the end result is that repeated calls to dll_populate_container_of_s cause more & more memory to be consumed. Does anyone have a solution or workaround for this? Or an alternate pool allocator? Thanks Andrew ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.