🚀 go-pugleaf

In article <AC95AF519668119E08@sleipner.nts.mh.se> lars.farm@nts.mh.se (Lars Farm) writes:
> In article <9527400.19710@mulga.cs.mu.OZ.AU>,
> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
> 
> >I think the assignment operator and copy-constructor of auto_ptr
> >ought to be declared private.  If you want to copy an auto_ptr,
> >then instead of writing
> >
> >	auto_ptr<T> y = x;	// copy constructor
> >	y = x;			// assignment operator
> >
> >
> >you should have to write
> >
> >	auto_ptr<T> y = x.release();
> >	y = x.release();
> >
> >This makes it clear that x is being modified.
> 
> Nowhere else in a c++ program will a valid ptr_a become invalid by:
> 
>   ptr_b = ptr_a;
> 
> Nowhere else in a c++ (or any other) program will the rhs be altered by
> assignment.
> 
> If I really want to transfer ownership I can do
> ptr_b.reset(ptr_a.release()); If I'm unaware of the danger, the compiler
> will point me in the right direction. As it stands it will be quite hard
> to explain to students why this must behave so counterintuitively. 
> IMHO the simpler version with private copy/op= will also be easier to
> use.
> 
> Also:
> 
> void f( auto_ptr<X> ); // this might not make sense (to you), 
>                        // but you must be aware of the dangers 
>                        // with auto_ptr to know... many wont be
> void g()
> {
>    auto_ptr<X> x( new X );
>    ...
>    x->m     // x is valid
>    f( x );
>    x->m;    // oops... compiler would catch this with private copy-ctor
> 
> I think they should be private.

But we need the public copy constructor and assignment operator so we can
define a function that returns an auto_ptr pointer to a newly allocated object,
like the familar clone() member function found in many polymorphic class
hierarchies. How to return a pointer to a newly allocated object is a problem
I've been struggling with for years. All the alternatives I tried were 
unsatisfactory:

- Returning an ordinary pointer: this requires the user the manage the object's
life span explicitly, which is not obvious from just looking at the function's
prototype. Furthermore, managing heap-allocated objects through ordinary
pointers is almost impossible in the presence of exceptions.
- Returning a reference counting smart pointer: this either defeats a special
purpose allocator for the object's class or requires an extra memory reference
every time we access the object. The other thing I dislike about reference
counting pointers is that they have a tendency to produce many aliasing 
pointers to the same object.
- Returning a deep copying smart pointer: this gets very slow and sometimes
produces unexpected side effects from redundant calls to constructors and 
destructors.

The auto_ptr template is yet another alternative, and the one I currently use.
As Fergus and Lars point out, it's not perfect either, but it has none of
disadvantages above. If auto_ptr's copy constructor and assigment operator were
made private, programmers are going to write their own `strict ownership'
pointer templates because there is a genuine need for them. Given a choice, I'd
rather have a standard auto_ptr template that works like a red flag to me
saying ``careful, I insist on strict ownership'' than a variety of similar
things with different names and subtle differences in semantics.

- Wil Evers (wil@ittpub.nl)

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