Subject: Re: [boost] scoped_ptr deleter
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-09-16 12:40:08
Howard Hinnant wrote:
> 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.
> I also recommend supporting lvalue-reference D types.
> I also recommend deleter accessors which return *references* to the
> 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
> 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
99% agree with this. 1% is that I'd rather discourage to touch
scoped_ptr and develop a new pointer type (perhaps, unique_ptr).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk