[boost] More scoped_ptr ruminations

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-20 18:40:48

From: "David Abrahams" <dave_at_[hidden]>

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

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

What about the "delete slicing" issue? Should the following be prevented at
compile-time if Base has no virtual functions?

    scoped_ptr<Base> p(new Derived);

We could easily do that (I am using John Maddock's is_polymorphic template
successfully in Boost.Python).

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com