Re: [boost] Re: auto_array_ptr

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
think
> > 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.
>
> Toss::
> Because std:auto_ptr is everywhere and does everything except the
sizeof(T)
> test at the call to delete, and IMO that isn't enough justification for
> replacing it.
>
> Keep:
> 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
worth
> 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
disagree. :-)

> > (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.

I prefer

void f(auto_ptr<int> & p1, auto_ptr<int> & p2);

over

void f(auto_ptr<int> p1, auto_ptr<int> p2);

since

f(auto_ptr<int>(new int(1)), auto_ptr<int>(new int(2)));

may leak.

> > (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
ownership,
> 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

std::auto_ptr<X> factory();

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.