Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter?

Subject: Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter?
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-03-21 15:39:39

> 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 <boost_at_[hidden]>
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
>