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