[boost] Re: Re: scoped_ptr::reset and auto_ptr

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-30 13:19:32

Please interpret my comments not as criticism of the current state, but 
rather opinions on where we might go from here.

On Monday, September 30, 2002, at 01:24  PM, Peter Dimov wrote:

>> From Beman's post-Curaçao notes:
>
> "* Proliferation of Standard Library smart pointers is a serious 
> concern; if
> a policy-based smart pointer and a compatible shared_ptr were 
> available,
> they would be preferred; scoped_ptr, scoped_array, and shared_array 
> were
> not viewed favorably by many LWG members."

I can't speak for the rest of the people that were in the room that 
day.  But the opinion I voiced to others in that room is that we should 
proceed with caution.  I did not (and do not) want to standardize the 
wrong smart pointers, and I remain unconvinced that all of the smart 
pointer issues are sufficiently ironed out.  That effectively had me 
saying: No, I don't want to standardize scoped_ptr and shared_ptr.  It 
is not because I think these classes aren't worth standardizing.  It is 
because I don't think the subject is yet mature enough.  For one thing, 
I think move semantics (if it comes to be) could have an impact on 
smart pointer design.  Template typedefs are another possibly 
significant influence.  And (templated) opaque typedefs yet a third 
potentially influential factor.  By the time C++0X rolls around, I 
sincerely hope that we will be able to standardize something.  And I 
have no doubt that the experience garnered from boost will be 
invaluable to whatever decisions are made.

>>> A related question is how does adding the word release make the
>>> example any clearer, unless you would also do the same when
>>> transfering to shared_ptr?
>>
>> I'm all for consistency! :-)
>
> shared_ptr's case is different, as its reset is allowed to throw:
>
> shared_ptr<X> px;
> auto_ptr<X> px2;
>
> px = px2; // strong guarantee, px2 unchanged if reset throws
> px.reset(px2.release()); // px2 NULL, object destroyed if reset throws

Interesting example.  A possible (but not necessarily better) 
alternative which keeps the interfaces decoupled is:

px.reset(px2.get());
px2.release();

I've just reviewed my own code and found that I've used this pattern 
several times when transferring ownership out of a local auto_ptr-like 
type.

-Howard