🚀 go-pugleaf

In article <31153AC5.1776@suphys.physics.su.oz.au> John Max Skaller
<maxtal@suphys.physics.su.oz.au> writes:

> > 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);
> 	f(vx);
> 	vx[0]; // CRASH

This leads to an interesting question: given the (current or proposed)
semantics of auto_ptr<X>, how many situations can you think of where
it is actually useful and correct to transfer ownership from one
auto_ptr to another?  It really doesn't seem to work quite right in
most of the cases where you'd like to use it.  If, as I suspect,
ownership transfer is only rarely valid, then maybe it shouldn't be
given such innocent seeming syntax as assignment or copy construction.
Or maybe it should be removed entirely.

The auto_ptr template is still useful even if ownership transfer is
completely banned: you use it when you allocate something on the heap
and you want to be sure that it's deallocated at the end of a block or
in a destructor.  I'm beginning to think that the right decision is to
restrict auto_ptr to thas one simple use, instead compromising its
safety by trying to make it useful for other purposes as well.  Other
pointer templates (such as reference-counted pointers) would be better
for those other purposes.

It may not be possible to get those other pointer classes into the
standard, but, as John points out, that's not too bad so long as they
become a de facto extension.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]