🚀 go-pugleaf

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

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. 

[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.]

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au

[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

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

Eugene Lazutkin wrote:
 
> I didn't find standard equal-operators:
 
> template<class T>
> bool            operator== ( const auto_ptr<T>& l, const T* r )
>                         { return l.get()==r; }
 
> template<class T>
> bool            operator== ( const T* l, const auto_ptr<T>& r )
>                         { return l==r.get(); }
 
> template<class T>
> bool            operator== ( const auto_ptr<T>& l, const auto_ptr<T>& r )
>                         { return l.get()==r.get(); }
 
> template<class T>
> bool            operator!= ( const auto_ptr<T>& l, const T* r )
>                         { return l.get()!=r; }
 
> template<class T>
> bool            operator!= ( const T* l, const auto_ptr<T>& r )
>                         { return l!=r.get(); }
 
> template<class T>
> bool            operator!= ( const auto_ptr<T>& l, const auto_ptr<T>& r )
>                         { return l.get()!=r.get(); }
 
> It's pretty convinient.  It's good if you are going to create a STL
> container of auto_ptr's.  In this case you can use STL's algorithms.
> Otherwise each programmer should implement this functions manually.
 

I agree. I'd like to treat an auto_ptr similarly to a normal pointer. 
This means that operator== and operator!= need to be defined. I'd 
also like to be able to test if its null or not - using operator!() 
and operator int().

Randal Parsons.

[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

In message <AUSTERN.96Feb5113807@isolde.mti.sgi.com> - austern@isolde.mti.sgi.c
om (Matt Austern) writes:
[...]
:>:>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?  
[...]

We pass ownership of objects around.  In C you had to "know" if
ownership was passed to know who was responsible for the object.
auto_ptrs with copy and assignment seem fine to me.  You
only do it when you are passing ownership.  As a parameter
I would pass the actual pointer or a ref rather than the autoptr if I 
expected to retain ownership.  On return values it means than the caller
is receiving ownership of an object.  You still can have the dangling 
reference problem, but if that is important (I rarely see it in my 
environment) you use reference counted pointers.


Ken Walter

* All the above is hearsay and the opinion of nobody in particular


[ 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://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]