Boost logo

Boost :

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:


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


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