🚀 go-pugleaf

In article mKQD@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su>
writes:
>Hi!
>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. If, as I suspect, its inclusion was prevented
>by the problem of efficiently allocating the counter in ref.counted
>pointer, then we could parameterize auto_ptr WRT not only the type, but
>allocator as well. Also, we could use doubly-linked list instead. And
>anyway, it is the implementation problem!

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.

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

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.

(Yes, examples are known where multiple ownership does what you want.
That doesn't mean it is overall the best design. And nothing prevents
you from writing your own multiple-owner class.)

---
Steve Clamage, stephen.clamage@eng.sun.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. ]

In article <4djrn4$js1@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes:

> 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.
> 
> 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 thought it was generally agreed that auto_ptrs as currently defined
were broken---specifically, that the semantics of strict ownership,
constness, and the binding of temporary objects, ended up making an
auto_ptr nearly useless for returning a value from a function.  That's
unfortunate, since returning something from a function is one of the
situations when it's most important to have some safe wrapper class 
like auto_ptr.

I've spent a bit of time trying to come up with bright ideas for
fixing auto_ptr, but I don't really have any.  Reference-counted
pointers don't have this particular problem, though, and that might be
the best argument for putting rc_ptr in the standard in addition to
(or instead of) auto_ptr.
-- 
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. ]

In article <AUSTERN.96Jan18103535@isolde.mti.sgi.com> austern (Matt
Austern) writes:

> In article <4djrn4$js1@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes:

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

> > 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 thought it was generally agreed that auto_ptrs as currently defined
> were broken---specifically, that the semantics of strict ownership,
> constness, and the binding of temporary objects, ended up making an
> auto_ptr nearly useless for returning a value from a function.  That's
> unfortunate, since returning something from a function is one of the
> situations when it's most important to have some safe wrapper class 
> like auto_ptr.

The only thing I think where there was anything like universal agreement
was that auto_ptr's are nearly useless unless you can copy a temporary
auto_ptr object.  In the exact form that they are described in the
standard, you cannot.  But there were a number of proposed solutions,
most of which maintain the concept of strict ownership.

> I've spent a bit of time trying to come up with bright ideas for
> fixing auto_ptr, but I don't really have any.  Reference-counted
> pointers don't have this particular problem, though, and that might be
> the best argument for putting rc_ptr in the standard in addition to
> (or instead of) auto_ptr.

I use reference counted pointers a lot, but they have their own set of
problems.  I can very well understand the committees reluctance to adapt
them.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]

J. Kanze wrote:

> I use reference counted pointers a lot, but they have their own set of
> problems.  I can very well understand the committees reluctance to 
> adapt them.

Can you share with us the problems with reference counter pointers?
How do those problems compare with the auto_ptr problems?  Perhaps
we need some kind of hybrid between the two.

Bowden

--------------------------------------------------------------------
G. Bowden Wise
Computer Science Dept, Rensselaer Polytechnic Inst, Troy, NY 12180
Email: wiseb@cs.rpi.edu         WWW: http://www.cs.rpi.edu/~wiseb/

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


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

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