shared_ptr - allocator template argument
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.
Michael Schneider wrote:
Is there a reason why shred_ptr does not accept an allocator?
shared_ptr doesn't have an allocator template parameter because this would encode an implementation detail into its type. An important design principle of shared_ptr<T> is to hide such specific requirements behind an opaque type that just "does the right thing" when it comes to deallocation/destruction. This doesn't mean that shared_ptr shouldn't accept an allocator, though. The proper way to add allocator support would be via an additional constructor: template<class Y, class D, class A> shared_ptr( Y * p, D d, A a ); and a corresponding reset. Now in CVS. ;-)
- If a change is required, what can I do to help make this change in boost (I am new to the boost community)?
You can contribute a test for the new functionality. :-)
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:002801c5e56a$a6d88930$6401a8c0@pdimov2...
Michael Schneider wrote:
Is there a reason why shred_ptr does not accept an allocator?
shared_ptr doesn't have an allocator template parameter because this would encode an implementation detail into its type. An important design principle of shared_ptr<T> is to hide such specific requirements behind an opaque type that just "does the right thing" when it comes to deallocation/destruction.
This doesn't mean that shared_ptr shouldn't accept an allocator, though. The proper way to add allocator support would be via an additional constructor:
template<class Y, class D, class A> shared_ptr( Y * p, D d, A a );
and a corresponding reset.
Now in CVS. ;-)
- If a change is required, what can I do to help make this change in boost (I am new to the boost community)?
You can contribute a test for the new functionality. :-)
I don't understand. Looking at sp_counted_impl.hpp, it appears that there already is a way to do this in the current shared_ptr implementation, using the following steps: - Define BOOST_SP_USE_QUICK_ALLOCATOR - Make sure BOOST_SP_USE_STD_ALLOCATOR is not defined - Create an instance of the quick_allocator class template for the class you are using with shared_ptr, redefining the quick_allocator instatiation's alloc and dealloc functions as needed Am I wrong in my interpretation of that code? I will acknowledge, however, that your approach above, with the three parameter constructor, is the more proper way to add a custom allocator. Michael Goldshteyn
participants (3)
-
Michael Goldshteyn -
Michael Schneider -
Peter Dimov