Custom deleter for ptr_vector?
Hi, I was wondering it is currently possible to give ptr_vector a custom deleter? This could simply be in the form of a functor. If this feature does not exist, would it be hard to add? For example, you could do this: namespace boost { namespace detail { template< typename t_type > struct default_deleter { void operator() ( t_type* ptr ) { delete ptr; } }; } template< typename t_type, typename t_deleter = detail::default_deleter<t_type> > class ptr_vector { private: std::vector<t_type*> m_pointers; public: ~ptr_vector() { std::for_each( m_pointers.begin(), m_pointers.end(), t_deleter() ); } }; }
On 18/01/2008, Robert Dailey <rcdailey@gmail.com> wrote:
I was wondering it is currently possible to give ptr_vector a custom deleter?
It looks like you might just have to overload delete_clone in a way that lets it be found through ADL ( http://boost.org/libs/ptr_container/doc/reference.html#the-clonable-concept ) or, if you need different deallocators for the same type, make a Clone Allocator ( http://boost.org/libs/ptr_container/doc/reference.html#the-clone-allocator-c... ) ~ Scott -- Sed quis custodiet ipsos custodes?
It looks like you might just have to overload delete_clone in a way that lets it be found through ADL (
http://boost.org/libs/ptr_container/doc/reference.html#the-clonable-concept ) or, if you need different deallocators for the same type, make a Clone Allocator (
http://boost.org/libs/ptr_container/doc/reference.html#the-clone-allocator-c... )
Thanks, I'll look into that and see if it works. However, I like the method I proposed in my first email better. Is there a reason why it could not be done this way? It seems more intuitive and simple. In addition, you wouldn't need to rely on ADL.
On 19/01/2008, Robert Dailey <rcdailey@gmail.com> wrote:
Thanks, I'll look into that and see if it works. However, I like the method I proposed in my first email better. Is there a reason why it could not be done this way? It seems more intuitive and simple. In addition, you wouldn't need to rely on ADL.
Your idea is basically the same as specifying a clone allocator. The only difference is that the clone allocator needs to know how to allocate objects, not just deallocate them, since you can v.push_back(4) into a ptr_vector<int> v. SFINAE means that you might even be able to get away with only the deallocator, at the cost of a (possibly severely) reduced interface. ~ Scott
Scott McMurray skrev:
On 19/01/2008, Robert Dailey <rcdailey@gmail.com> wrote:
Thanks, I'll look into that and see if it works. However, I like the method I proposed in my first email better. Is there a reason why it could not be done this way? It seems more intuitive and simple. In addition, you wouldn't need to rely on ADL.
Your idea is basically the same as specifying a clone allocator. The only difference is that the clone allocator needs to know how to allocate objects, not just deallocate them, since you can v.push_back(4) into a ptr_vector<int> v.
That is not correct. That syntax was part of the review version, but not the final interface. You would have to do v.push_back( new int(4) ); Also, you don't have to rely on ADL at all. The Cloable Concept relies on ADL, but the CloneAllocator concept does not. So implement your own CloneAllocator thereby also specifying how you want to delete objects. -Thorsten
participants (3)
-
Robert Dailey -
Scott McMurray -
Thorsten Ottosen