Boost logo

Boost :

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
> 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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at