Re: [boost] scoped_ptr deleter

Subject: Re: [boost] scoped_ptr deleter
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-09-16 12:40:08

Howard Hinnant wrote:

[snip]

> If this community does decide to 
> put a custom deleter into scoped_ptr (and I am ambivalent on that 
> decision), then I strongly encourage the designers of this patch to 
> mimic the custom deleter of unique_ptr.

[snip]

> I also recommend supporting lvalue-reference D types.

[snip]

> I also recommend deleter accessors which return *references* to the 
> deleter:
> 
>    D& get_deleter();
>    const D& get_deleter() const;
> 
> It is not uncommon to need access to the actual stored deleter (not a 
> copy of it) during the lifetime of the smart pointer (I needed this just 
> yesterday in code I was writing).  This is used to change the state of 
> the deleter which alters the behavior the deallocation process (e.g. do 
> (or don't) destruct a certain field in the held object).
> 
> And you'll want scoped_ptr constructors which accept a deleter (to 
> initialize its state).  And you'll want to disable the constructors 
> which don't take a deleter when D is a pointer or reference type (lest 
> it be null).
> 
> scoped_ptr<A[]> could be a nice synonym for scoped_array<A> if 
> checked_deleter is specialized for T[].  It is nothing more (or less) 
> than a nice, easy to remember name for the array variant of the smart 
> pointer.
> 
> When you get done, you will have reinvented all of the const parts of 
> unique_ptr (which has several years of refinement under its belt by 
> now).  I don't necessarily discourage that as it is a very educational 
> exercise.

99% agree with this. 1% is that I'd rather discourage to touch 
scoped_ptr and develop a new pointer type (perhaps, unique_ptr).