🚀 go-pugleaf

On 	Sunday, February 04, 1996 6:09 PM, 
John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:
> Eugene Lazutkin wrote:
> [auto_ptr]
> 
> > It's good if you are going to create a STL
> > container of auto_ptr's.  
> 
> 	EGADS! NEVER DO THIS!!!!
> 
> 	The following will CRASH FOR SURE:
> 
> 	void f(vector<auto_ptr<X> >){}
> 	vector<auto_ptr<X> > vx; vx.push_front(new X);

You're right.  push_front() for vector<> is not good idea! :-)

> 	f(vx);

This is a very time-consuming operation. You should use it if it 
is really essential for you.

> 	vx[0]; // CRASH

Right.  I have a shorter example to demonstrate the same behavior.
It doesn't use STL at all!

	// declarations
	typedef	auto_ptr<T>	aptr;
	void	f( aptr );

	// example
	aptr	p( new T );
	f( p );
	*p;	// CRASH

What's your point?  I agree with your that non-reference counting
(or non-garbage collecting) pointers are dangerous.  I mean both
C-style old-fashioned pointers and current auto_ptrs.  But you can
write a program which doesn't violate certain restrictions.

To me auto_ptr is useful under certain circumstances. It's better 
than nothing. At least in this case I can control the life of the 
pointed object (if I write my program correctly).  Garbage collection
doesn't guarantee anything.

It's sad that reference counting was rejected by the committee.
Maybe it was a better choice.

> Copying the container transfers ownership to the NEW container.
> You must NOT use FIFO/block structure here: if the new
> container is destroyed before the old one, all the auto_ptrs
> in the old container dangle.
> 
> Even worse, if you have an input iterator onto the container
> which returns an rvalue, dereferencing it steals ownership
> from the container by creating a copy -- the destruction
> of which will delete the object, leaving the container's
> auto_ptr dangling. 

You have the same problems without any containers.

> [Correct use of the idiom requires the newest copy of
> an auto_ptr outlive use of older ones. This is often
> achieved by assigning the newest value back to the object
> it was copied from.]

Eugene Lazutkin
eugene@int.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]