Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-20 20:37:30

On Friday, September 20, 2002, at 07:24 PM, David Abrahams wrote:

> The more I think about scoped_ptr the harder it gets to justify using
> it.
> It still has explicit transfer-of-ownership via reset(), though
> there's no
> implicit transfer-of-ownership. In some sense, std::auto_ptr<T> const
> is a
> better candidate for the role that I've always thought scoped_ptr was
> playing, since there is no reset() member. The case where you need to
> default construct a smart pointer and later initialize it is enough of
> a
> corner that I'd be inclined to recommend a straight-up auto_ptr for
> that. I
> guess the only downside to auto_ptr for that role is the
> automatically-generated copy constructor and assignment operator. When
> we
> get move_ptr
> (
> n1377.htm#move_ptr%
> 20Example) we'll be all set ;-)

I can see several useful smart pointers here (though I do not yet know
their names):

1. no copy semantics, no move semantics.
scoped_ptr without a reset, or as you note const auto_ptr could satisfy

2. move semantics, no copy semantics.

3. copy semantics, no move semantics.
shared_ptr, and/or a deep-copy "clone ptr" could fill this role.

4. copy semantics, move semantics.
Same as #3. Once you have copy semantics, move semantics is just an
optimization. It should not effect interface.

Imho, if/when move_ptr becomes a reality, auto_ptr is fatally flawed
because of the "moves with copy syntax" behavior. At that point
scoped_ptr could still have an advantage over move_ptr if it said:
"this smart pointer *will_not* transfer ownership." i.e. scoped_ptr
might have to jettison reset. Otoh, const scoped_ptr, const move_ptr,
and const auto_ptr all have #1 semantics.

> Well, OK, there's the "deletion of incomplete type" issue (use of
> checked_delete) which is also not provided by auto_ptr.

If I'm not mistaken, this issue is orthogonal to the ownership issue.
Could this technology not be integrated into any smart pointer with no
run time or space overhead?

hmm... Definitely a subject worthy of ruminations! :-)


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