From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-04-05 12:10:25
From: "Gary Powell" <Gary.Powell_at_[hidden]>
> > AFAIK auto_ptr_ref supports passing/returning auto_ptrs by value. I
> > that this is unnecessary for boost::auto_ptr, since
> > (1) we have
> > boost::shared_ptr for this,
> I was thinking of dropping boost::auto_ptr.
> But I'm open to comments here.
> Because std:auto_ptr is everywhere and does everything except the
> test at the call to delete, and IMO that isn't enough justification for
> replacing it.
> The my reason for keeping it, is that this change should become part of
> std::auto_ptr and in order to prove to the library committee that its
> doing, there should be some prior usage.
I think (as Steve Cleary pointed out) that the current rules allow
std::auto_ptr to check for incomplete types.
Whether we need boost::auto_ptr is an interesting question. I'd always use
std::auto_ptr, especially in interfaces (to reduce couplings.) Then again, I
don't see the point in having boost::scoped_ptr either, but obviously others
> > (2) passing auto_ptrs by value instead of
> > non-const reference is dangerous (exception safety), and
> I thought that was the second main purpose of auto_ptr. See
> shared_ptr<>(auto_ptr<>() ); constructor, and assignment.
void f(auto_ptr<int> & p1, auto_ptr<int> & p2);
void f(auto_ptr<int> p1, auto_ptr<int> p2);
f(auto_ptr<int>(new int(1)), auto_ptr<int>(new int(2)));
> > (3) returning
> > std::auto_ptrs by value is sometimes useful since std::auto_ptr is
> > standard,
> > but boost::auto_ptr is not, so it doesn't need this "capability."
> Again, I thought this was the third main purpose of auto_ptr, returning a
> pointer to allocated memory, forcing the calling function to take
> and not leak memory.
True, but you can return a shared_ptr as well. The standard doesn't have a
shared_ptr, so std::auto_ptr has been "enhanced" to support this idiom.
My other point is that when I'm designing an interface
I'd prefer std::auto_ptr over boost::auto_ptr in order to not force clients
to use boost.
> This way if shared_array( auto_array_ptr<>(new T[n] ) throws when it
> allocates the new for the pointer to the counter it won't leak the T[n].
shared_array(new T[n]) will not (should not :-) ) leak.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk