🚀 go-pugleaf

gregor@netcom.com (Greg Colvin) writes:
>The smallest change I can see that preserves the semantics of strict 
>ownership is to separate the concepts of "holding a pointer" and "owning 
>an object", so that more than one auto_ptr can hold a pointer to an object,
>but only one auto_ptr can own the object.  

Your new proposal is a recipe for dangling pointers.  What about the
following program:

main () {
    auto_ptr<int> outer = new int;
    {
	auto_ptr<int> inner = outer; // inner now owns the int
	// end of inner's scope, int is deleted
    }
    *outer = 1;			// crash
}

Under the old rules for auto_ptr, after the copy constructor for inner,
outer's internal pointer would be null, and I could test for this
(outer.get() == 0).  Under your proposed change, though, outer contains
a dangling pointer.

I don't see a way around reference counts if you want a class that
contains a pointer and can do copies and assignments using the expected
semantics and guarantees to clean up the heap object.  

We could still have plain auto_ptr, but with no assignment operator and no
copy constructor, and with an explicit member function for transferring
ownership.  This means that a function cannot return an auto_ptr, but it
could still return one through a reference parameter.
-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]