A poly_deleter really should not hold just a function pointer as a deleter. The custom deleter may be any function, containing any amount of state (it could for example be returning resources to a memory pool, or managing a semaphore). fixing the deleter type at `void (*)(void*)` is a no-go. It's not useful. On 21 March 2017 at 15:33, Andrey Semashev via Boost wrote:

On 03/21/17 16:33, Andrey Davydov wrote:

...

On Tue, Mar 21, 2017 at 4:11 PM, Andrey Semashev mailto:andrey.semashev@gmail.com> wrote:

struct poly_deleter { template< typename T > poly_deleter(T* p) : m_p(p), m_delete(&poly_deleter::do_delete< T >) { }

void operator() (void*) const noexcept { m_delete(m_p); }

private: template< typename T > static void do_delete(void* p) noexcept { delete static_cast< T* >(p); }

void* m_p; void (*m_delete)(void*); };

This will work even if you form std::unique_ptr (i.e. don't have a universal base class).

Your poly_deleter implementation is the same as I used inside my smart pointer implementation, but there is an issue with std::unique_ptr, namely it is not constructible from std::unique_ptr because poly_deleter must capture pointer and so it is not constructible from std::default_delete.

I think that problem can be solved by make_poly_unique or a conversion helper function. Hardly a whole new smart-pointer is an adequate solution.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

Carrying around a fat deleter in every pointer instance is what I consider a no-go.

Nevertheless, there are many scenarios where it would be important. And in keeping with the well-understood interfaces of shared_ptr and unique_ptr, I strongly suggest it would be demanded by the community. By all means have a specialisation of the deleter's implementation for this case - it's a useful optimisation. Some scenarios where you'd want a "fat" deleter: 1. you need to return objects to a pool 2. you need to release a semaphore 3. you need to post a notification on a message queue 4. deletion is necessarily constrained by accessing a mutex. 5. the deleter isn't actually fat - it's a stateless class such as std::default_delete! I still agree that a type-erased-deleter-unique_ptr is useful. One that could only accept a function pointer as the deleter would be surprising to anyone who has had contact with unique_ptr or shared_ptr. I could not support this constraint. On 21 March 2017 at 16:00, Andrey Semashev via Boost wrote:

On 03/21/17 17:53, Richard Hodges via Boost wrote:

...

A poly_deleter really should not hold just a function pointer as a deleter. The custom deleter may be any function, containing any amount of state (it could for example be returning resources to a memory pool, or managing a semaphore).

fixing the deleter type at `void (*)(void*)` is a no-go. It's not useful.

If you want something more generic then just use std::function as a deleter. It's been mentioned earlier in the thread.

Personally though, I don't remember needing anything more elaborate than a `void (*)(void*)` function or similar. Probably because if I need something more advanced, I'll likely choose a virtual destructor or shared_ptr or intrusive_ptr. Carrying around a fat deleter in every pointer instance is what I consider a no-go.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost