🚀 go-pugleaf

Steve Clamage wrote:
> 
> In article mKQD@qsar.chem.msu.su, "Eugene Radchenko"
> <eugene@qsar.chem.msu.su> writes:
> >I would like to suggest returning to the definition of auto_ptr. The fact
> >is, in current form it is almost unusable for most things due to its
> >underlining concept of a single strict ownership. Actually, we need
> >multiple-instance auto_ptr. 

> That point has been beaten to death in the C++ committee and also in
> this forum. Some people felt an auto_ptr should be able to have multiple
> owners, but people with experience with this kind of design persuaded
> the committee that auto_ptrs are too hard to use unless they can have
> only a single owner. Thus, ownership is transferred upon copying.

	This is fairly biased picture -- from my perspective.
	Here's what actually happened -- from my perspective.

	1. There was a clear need from some kind of automatic
	   storage management for pointers, particularly in the light of
	   exceptions.

	2. Australia, New Zealand and the UK made "Exception safe programming"
	   with pointers National Body Issues. Not everyone was happy at
	   having to deal with this. [In retrospect, they might have been
	   right.]

	3. I submitted the first design to the Library reflector.
	   The class was called "Holder". Mike Vilot (LWG leader) did some
		    [[ Moderator's note: for the uninitiated,              ]]
		    [[ "LWG" == "Library Working Group". -moderator (fjh). ]]
 	   work on it. Holder had an important property -- it was NOT copyable.

	   I also said a reference counted smart pointer type
	   was necessary, although I didn't have an adequate design handy.
	   This was the kind to use when you needed copyability.

	4. The design was eventually taken over by Greg Colvin.
	   (Greg is a top designer, his first proposal was extremely
	    ambitious -- garbage collection!)

	5. Despite REPEATED attempts, Greg was not able to engineer
	   a proposal for a reference counted pointer that the committee
	   could agree on. [But I currently use his design myself,
	   it will be published in my book as "ColvinPtr"]

	6. Because this left a huge gaping hole, the Holder class -- which
	   had been renamed "auto_ptr" by this time, was mangled to try to
    	   serve two masters. The semantics were changed to
	   "token passing", which was never in my original Holder class,
 	   nor implied by a reference counting implementation,
	   and does not, in my opinion, meet Australia's requirements.

	7. Then it was discovered that the current specification is useless
	   because it requires a non-const argument to the copy constructor.

	8. Just today I read Greg has proposed using "mutable" to fix
	   the problem.  The semantics have changed radically in this
	   proposal: now ALL the auto_ptr objects can access the
	   object, but only one is designated as the owner.

	For the record, I have no objections to token passing per se --
it's just another storage management idiom. What I object to is the use
of copy syntax for a non-copying operation, and the fact that this
idiom is far less useful than reference counting, and not constrained
enough for a Holder style class.

	It is, for example, useless as a replacement
for pointers in classes whose constructors might throw exceptions,
since copying the object silently transfers ownership. The new
object will then promptly destroy the delegee object, invalidating
the pointer in the old one prematurely.

> That is, single ownership is a deliberate design decision based on the
> semantics an auto-ptr should have. It is not an implementation issue.

	I do not agree. It is definitely an implementation
issue when the proposed semantics are unimplementable without
resorting to hackery -- in this case "mutable".

	And the current attempt to fix the problem is an not an example
a deliberate design decision, but a brilliant designer trying
to cope with the political situation in the committee -- changing
the specification of auto_ptr is acceptable, creating
a new class is not.
 
> Unless someone can present new evidence that shows the arguments in favor
> of single ownership are wrong, and in addition shows that multiple
> ownership is always better, this subject won't be reopened in the committee.

	I don't agree with that either. You are making
the committee sound logical. It isn't. It is political.

	The committee will (correctly, IMHO), not reopen
the issue unless a National Body (or three!) requires it.
No amount of argument or evidence is relevant. The committee
will tolerate fudging the semantics of the existing class,
but won't address the _original_ National Body requirements.

	Will I find myself annoyed at this outcome, the need
to stablise the language overrides any but the most
fundamental design faults in the core language itself -- IMO.
So we may have to live with auto_ptr -- but we don't HAVE to
use it.

-- 
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://dogbert.lbl.gov/~matt/std-c++/policy.html. ]