I'm looking for what type of interest is there for a policy base smart pointer like that in the following link: http://code.axter.com/smart_ptr.h 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> pShape; Instead of this: smart_ptr<Shape, deep_copy_policy<Shape> , clone_function_allocator_policy<Shape> > pShape; or worse: smart_ptr<Shape, deep_copy_policy<Shape, clone_function_allocator_policy<Shape> > > pShape; The above smart pointer currently has copy_on_write_policy, shared_ptr_policy, deep_copy_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 size. 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. Thanks