[boost] Re: auto_ptr in collections

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-03 09:04:47

I'm not sure I understand why shared_ptr alone is not sufficient for your
purposes.  

auto_ptr and shared_ptr are different animals altogether.  The auto_ptr
class has a strict pass-the-baton method of ownership behavior.  Only one
auto_ptr can have access to a pointer at once.
The shared_ptr class, since it uses a shared reference count, allows
multiple objects to "own" a pointer at once. The reference count is
incremented on assignment and copy construction, and decremented on
destruction and reassignment.  When the reference count hits 0, there are no
more references and the resource can be deleted.

If you still think you need to be able to convert a shared_ptr to auto_ptr,
you should check out the previous discussions about release on boost.  In
the end, there seemed to be consensus on defining the behavior of release as
a reset(0) without delete, returning 0 if unique() returned false.  This
limited definition provided the release functionality in most cases it would
be needed, but without leaving dangling shared_ptrs around.

For better definition of this behavior, see
http://www.egroups.com/group/boost/2128.html?

> -----Original Message-----
> From: Paul Jensen [mailto:pdjensen_at_[hidden]]
> Sent: Thursday, March 02, 2000 5:31 PM
> To: Steve Clamage
> Cc: boost_at_[hidden]
> Subject: [boost] Re: auto_ptr in collections
> 
> 
> Steve Clamage wrote:
> > John Nagle wrote:
> > >    Did the use of collections with auto_ptr elements ever 
> get fixed,
> > > or is that still broken?
> > ...
> > The various complaints about auto_ptr all boil down to having
> > conflicting sets of requirements. They can't all be satisfied
> > at once. I think a future C++ standard could have a collection of
> > safe-pointer classes, each with different semantics.
> 
> I've been trying to find a reasonable safe-pointer 
> representation to hold the
> ownership of a class data member - ie, replace class C { TYP 
> *t; ... }; with
> class C { class_template<TYP> t; } where the class C is 
> intended to have value
> semantics, and the cctor and op= for class_template<TYP> 
> either copy the object
> of type TYP, or share it. 
> 
> C's members need to change t's value, and that seems to 
> require auto_ptr as the
> appropriate argument type for passing the ownership in and out.
> 
> auto_ptr<TYP> fails to work unless C's cctor and op= deal 
> with it explicitly.
> 
> Boosts shared_ptr<TYP> seems to address the problem, but I've 
> found no way to
> modify its value since there is no release() capability. 
> get() followed by
> reset() results in a dangling pointer, and swap() just 
> postpones the agony. I
> can't seem to convert shared_ptr => auto_ptr.

There are two ways to assign a shared_ptr to a new value, 
reset and operator=(const shared_ptr &).
Looks like you've used the first, here's the second.

shared_ptr<int> sp(new int(42));

sp = new int(7); // illegal, shared_ptr has explicit constructor
sp = shared_ptr<int>(new int(7)); // OK

> 
> Since this situation is akin to the problem of a collection 
> of owning pointers,
> I thought the solution would be the same. 
> 
> I'm attaching a short class declaration to sketch what I'd like.
> 
> Pointers?
> 	Thanks,
> 		Paul
> -- 
> Paul Jensen	Agile Image Movers	http://agileimage.com
> 
> --------------------------------------------------------------
> ----------
> Planning a party? iParty.com is your complete source for 
> party planning and
> supplies, with everything you need to throw the perfect party!
> http://click.egroups.com/1/1635/1/_/9351/_/952049140/
> 
> -- Check out your group's private Chat room
> -- http://www.egroups.com/ChatPage?listName=boost&m=1
> 
>