From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-19 18:13:17
I'm looking for what type of interest is there for a policy base smart
pointer like that in the following link:
I read in a previous thread that a policy base smart pointer was being
considered for boost, but I could not find it in the sandbox.
The above policy base smart pointer is different from other similar
smart pointer in that it does not inherit any of the policies.
Only one of the policies (OWNERSHIP_POLICY) is used as a data member.
The remaining policies use a static member function interface.
This allows for the following type of declaration:
smart_ptr<Shape, deep_copy_policy, clone_function_allocator_policy>
Instead of this:
smart_ptr<Shape, deep_copy_policy<Shape> ,
clone_function_allocator_policy<Shape> > pShape;
clone_function_allocator_policy<Shape> > > pShape;
The above smart pointer currently has copy_on_write_policy,
Moreover, these three types are interchangeable with each other.
Smart_ptr currently uses reference-link logic, and on my performance
test I found them to be able to out perform boost::shared_ptr on
initialization and on copying.
It would not be that hard to add reference-count ownership policy class,
but I haven't found any real benefit to using reference-count other then
The ALLOCATOR_POLICY can be used for both special allocators, and for
using different cloning methods.
Most clone function methods can only catch slicing at runtime. But the
clone_static_function_allocator_policy can be used to help stop slicing
at compile time. It's still not fail proof, but it's close.
I'm still working on the cow_ptr, shared_ptr, and ptr_vector comparison
article, but I'm looking to throw this smart_ptr into the mix, and
wanted some feedback on it.