🚀 go-pugleaf

Joe Buck wrote:
> 
> 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.  

	It is not Greg's current proposal which is
a recipe for disaster, it is the very notion of using
the copy operator to transfer ownership. IMHO.


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

	I agree completely.
 
> 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.

	Again, I agree completely, this was my original proposal:
TWO classes, one which was to be used simply to attach heap objects onto
the stack to allow the destructor to delegate to destroying the
heap object. This fixes the problem:

	void f() {
		X* x= new X;
		throw 1; // WOOPS, 
		delete x;
	}

	Since C++ stack frames are not copyable, copyability
in auto_ptr is not only not required, it's dangerous. The concept
is simply to SCHEDULE deletion at the point of construction:

	void f() {
		auto_ptr<X> x (new X); // SCHEDULES DELETION at #1
		throw 1; // OK: invokes block termination code
		// #1: termination code "delete x;" scheduled
	}

	This leaves the problem of pointers in copyable
objects -- for which reference counting is a solution
in acyclic cases.

	The problem with the "move" semantics of
the current auto_ptr is NOT the strict ownership
idiom -- it's the use of inappropriate copy syntax to
access that idiom.

	The solution -- IMHO -- is to ignore and NOT USE
auto_ptr, and take up where the committee failed:
attempt to obtain consensus amoung USERS on suitable
smart pointer classes. "Practice" will then push such
accepted and "in use" classes in to the _next_ standard.

	My UESTL/smart module is an attempt to provide
a coherent set of smart pointers. Mail me for a copy,
email comments welcome. [It's unclear if the charter of this
newsgroup allows for "public" comment on my "private"
attempt at standardisation. But the results will be published
in black and white by Prentice Hall. Someone has to
do this, since the committee wasn't able to. The set of
classes I have shows why the committe had trouble: more
than one class is required.]

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