|
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
> (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/
> 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
this.
2. move semantics, no copy semantics.
move_ptr.
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! :-)
-Howard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk