Is there a reason why shred_ptr does not accept an allocator? shared_ptr seems to allocate sp_counted_impl_p<...> using new, it it took in an allocator, then the allocator could be assigned the responsibility to allocate the memory for sp_counter_impl_p. We have an application requirement that all application memory must be managed by our memory allocation system. We have a secondary requirement that we can't replace global new and delete. It seems like this requirement could be satisfied by adding an allocator to shared_ptr. I could make this change locally, but it seems like this would be a common requirement that would be useful for several application domains. Couple of quick questions: - am I off in the weeds with this suggestion? Is there a simple way to meet our memory requirement without modifying shared_ptr?? - If a change is required, what can I do to help make this change in boos (I am new to the boost community)? If this is not useful to the community, please let me know. I can code this in internal code if that is best for the boost community. Thanks Mike -- The greatest performance improvement occurs on the transition of from the non-working state to the working state.