[boost] Re: scoped_ptr::reset and auto_ptr

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-30 10:51:16

I think the idea is that boost attempts to deprecate the usage of auto_ptr.
Thus, no reason for it to transfer out an auto_ptr.

"Ed Brey" <brey_at_[hidden]> wrote in message
news:an9qq9$uhq$1_at_main.gmane.org...
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:014001c26890$f82f8b80$1d00a8c0_at_pdimov2...
> > From: "Ed Brey" <brey_at_[hidden]>
> > > The constructor for boost::scoped_ptr's has an overload for
std::auto_ptr, which is good,
> > > IMHO.  However, its reset member has no similar overload.  This seems
like an oversight.
> > > Is it?
> >
> > The motivating case for this constructor was
> >
> > std::auto_ptr<X> createX();
> >
> > scoped_ptr<X> px(createX());
> >
> > Nobody requested a reset(auto_ptr) method. FWIW, shared_ptr uses
operator=
> > for this purpose, and not reset(), but scoped_ptr has no assignment
> > operators.
>
> Here is the equivalent motivating example for the reset overload:
>
> struct A {
>     scoped_ptr<X> px_;
>
>     initialize(std::auto_ptr<X>& p) {
>         px_.reset(p);
>     }
> };
>
> The argument for why the member variable should be a scoped_ptr (versus an
auto_ptr) is the same as the argument for why the automatic variable is a
scoped_ptr in your example.
>
> The thought of an operator= on scoped_ptr that takes an auto_ptr is an
interesting one.  Given that its constructor takes an auto_ptr, one could
say that scoped_ptr will "transfer in a pointer", but will not "transfer out
a pointer".  Given that definition of scope, an assignment operator that
transfers in a pointer seems necessary for completeness.
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>