"john (j.d.) hickin" <hickin@bnr.ca> writes:
>And this, the expectation that constructors of the form X(X&) and X(const X&)
>must perform a *copy* operation, is, IMHO, the trouble.

No, the notion that these constructors perform copy operations (and only
copy operations) is deeply wired in to the language, in at least three
places: argument passing, return value passing, and optimizing away of
copy constructors all assume these constructors mean "copy".

>The original term was reference constructor, a name which, in my opinion,
>carefully stepped around all subtleties of language.

I have never seen this term used.  Stroustrup said "copy constructor"
at a very early stage.

Anyone who writes a class in which X(X&) or X(const X&) does not have the
semantics of a copy operation is doing something wrong (e.g. auto_ptr in
the draft standard is broken).

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

|>The original term was reference constructor, a name which, in my opinion
|>carefully stepped around all subtleties of language.
|I have never seen this term used.  Stroustrup said "copy constructor"
|at a very early stage.

I have checked out a copy of the ARM (1990) and you are correct, Joe.
Apologies on my part are due.

I can't believe that I invented the term 'reference constructor' but I
have always used it.  Guess I'll have to change my ways!

On the off chance this usage was really old I dusted off my copy of
Stroustrups original book (1987 edition).  Although the term 'copy
constructor' isn't used there there is clearly an intent of copying
a value.

--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ 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 <4eucnc$hr9@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
Buck) writes:

|> "john (j.d.) hickin" <hickin@bnr.ca> writes:
|> >And this, the expectation that constructors of the form X(X&) and
|> >X(const X&) must perform a *copy* operation, is, IMHO, the trouble.

|> No, the notion that these constructors perform copy operations (and only
|> copy operations) is deeply wired in to the language, in at least three
|> places: argument passing, return value passing, and optimizing away of
|> copy constructors all assume these constructors mean "copy".

|> >The original term was reference constructor, a name which, in my opinion,
|> >carefully stepped around all subtleties of language.

|> I have never seen this term used.  Stroustrup said "copy constructor"
|> at a very early stage.

|> Anyone who writes a class in which X(X&) or X(const X&) does not have the
|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
|> the draft standard is broken).

I wouldn't go quite that far.  X(X&) is a particular form of copy,
which modifies the copied object.  If it is programmed in such a way
that the number of intermittent copies is meaningless (as is the case
in auto_ptr), then it is perfectly valid.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-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. ]

I wrote:
>|> Anyone who writes a class in which X(X&) or X(const X&) does not have the
>|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
>|> the draft standard is broken).

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
>I wouldn't go quite that far.  X(X&) is a particular form of copy,
>which modifies the copied object.  If it is programmed in such a way
>that the number of intermittent copies is meaningless (as is the case
>in auto_ptr), then it is perfectly valid.

You're not really disagreeing with me, James.  X(X&) is a reasonable
thing to do in some cases, and the source object will then be modified,
but if this operation does not look like a copy that leaves the
functioning of the argument object mostly unaltered, the user of the class
is going to have problems and surprises.  Many uses of X(X&) just modify
private members to keep some sort of internal record, e.g. how many copies
there are and connections between them.


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

In article <4fbapm$lbk@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
Buck) writes:

> I wrote:
> >|> Anyone who writes a class in which X(X&) or X(const X&) does not have the

> >|> semantics of a copy operation is doing something wrong (e.g. auto_ptr in
> >|> the draft standard is broken).
>
> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
> >I wouldn't go quite that far.  X(X&) is a particular form of copy,
> >which modifies the copied object.  If it is programmed in such a way
> >that the number of intermittent copies is meaningless (as is the case
> >in auto_ptr), then it is perfectly valid.
>
> You're not really disagreeing with me, James.  X(X&) is a reasonable
> thing to do in some cases, and the source object will then be modified,
> but if this operation does not look like a copy that leaves the
> functioning of the argument object mostly unaltered, the user of the class
> is going to have problems and surprises.  Many uses of X(X&) just modify
> private members to keep some sort of internal record, e.g. how many copies
> there are and connections between them.

That's what mutable is for.

I have no problems with the desired semantics for auto_ptr, for example.
Copy and assignment modify the copied/assigned from object completely.
They render it invalid.  You can hardly say that this is leaving the
object `mostly unaltered'.  However, the number of intermediate objects
is irrelevant; the function is transitive.  The `copy' is actually more
of a `move'.

Perhaps one of the reasons I want auto_ptr so badly in the standard is
that this is *not* something you would want to do in an arbitrary user
class, anymore than you would want to redefine left shift to mean input.
It because valid because it *is* part of the `standard' language;
everyone knows and uses it in this way.
--
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.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <AB29a1naHH@qsar.chem.msu.su> "Eugene Radchenko"
<eugene@qsar.chem.msu.su> writes:

> The fact is, multiauto_ptrs can be used in every place where singleauto_ptr
> can. The only possible drawback is the overhead in performance (negligible
> as compared to memory allocation - especially for list implementation) and
> storage (not so terrible as current compilers are not likely to put
> single_ap in register anyway).

By multiauto_ptr's, I presume you are refering to what are sometimes
called counted_ptr's.  If so, I explained the problems (at the
standardization level) in another posting.

> On the other hand, single_ap can't be put in
> STL container, can't be returned from the function, etc. Thus, the only its
> possible use is ensuring that temporarily allocated object is deleted on
> exception throw. (I would appreciate J.Kanze explaining the workarounds he
> mentioned in another follow-up).

The only `work-arounds' I can remember discussing are at the
implementation or standardization level.  I have my own implementation
of auto_ptr, which I use in containers (not STL, but the same basic
principal), as return values from functions, etc., etc.  In my case, I
simply declared the parameter to operator= to be a const reference
(instead of non-const), and cast away const in the implementation.  It's
not very pretty, but it gives me the single owner semantics defined in
the standard, while still allowing me to use the pointer in common
circumstances.

There was a long discussion on this subject here not too long ago, and I
don't really want to open it up again.  I think it would be safe to
assume that enough of the standards committee members read this forum
(the chairman is, after all, one of the moderators), and that the
results of this previous discussion are being considered in the
standards committee.  This is certainly not the most important thing the
committee has to attend to, decisions in such a committee take time, and
there is not a `draft standard of the week'; in these conditions, I
think it only fair to give the committee time to act before re-opening
the question.
--
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. ]

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

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

And this, the expectation that constructors of the form X(X&) and X(const X&)
must perform a *copy* operation, is, IMHO, the trouble.  The original term was
reference constructor, a name which, in my opinion, carefully stepped around
all subtleties of language. Copy is a loaded term because the C++ meaning
and the English langauge definition are not the same.

--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca


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

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

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

[snip]

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

[snip]

I would like to know what happened to the suggestion that the choice of
having temporaries be const be changed to a more relaxed rule.  I do not
recall the exact wording of the proposition, but I believed it only put
const on temporaries that were the result of a conversion.

Has it even been discussed ? I do find it quite cynical that this exact
choice (temporaries are const) makes it hard to use auto_ptr in return
value (and some other uses too in smart pointer), while most compiler have
a switch to allow non-const temporaries (and thus disabling any protection
from unexpected conversion on function argument that was the original
intent).

If it was rejected, I'd like to know on what ground, if anyone recalls.
---
[ 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. ]

dak wrote:
[text elided]
|> Has it even been discussed ? I do find it quite cynical that this exact
|> choice (temporaries are const) makes it hard to use auto_ptr in return
|> value (and some other uses too in smart pointer), while most compiler have
|> a switch to allow non-const temporaries (and thus disabling any protection
|> from unexpected conversion on function argument that was the original
|> intent).

Perhaps the assumptions underlying the original decree are no longer valid
because of the extra control over conversions available in 'standard C++'.

Permit me to open a can of worms...

I can implement a version of auto_ptr that is fully const correct because the
implementation uses a pointer to a pointer to hold onto the basic resource.

One could, therefore, argue that because a const correct implementation can
exist that an implementation with the same observables, but with const
correctness twisted a bit, should be OK.  (See note 1 below).

One could also turn this about-face; the net result of banishing the proposed
hackery being an argument in favour of deep const.  I warned you about a can of
worms!

J.


Notes:
-----

1. As far as I can see, true const correctness with a pointer-to-pointer
   implementation might require bounding the number of auto_ptr instances.
   The implementation, therefore, would not quite live up to the spec for
   auto_ptr (but in any practical system there will be an upper bound).

--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ 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. ]

Hello!

clamage@Eng.Sun.COM (Steve Clamage) writes
>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.

Could you explain please? I understand that multi_ap may be harder to
implement, but using them are much simpler. Also, why is it called _copy_
constructor - it is in fact the _move_ constructor. (Generally, is it wise
to call X(X&) the copy constructor?)

>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 never said that strict/multiple ownership is an implementation issue. I
was talking about whether to implement multiple-ownership auto_ptrs using
ref.counting, list or something else.

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

The fact is, multiauto_ptrs can be used in every place where singleauto_ptr
can. The only possible drawback is the overhead in performance (negligible
as compared to memory allocation - especially for list implementation) and
storage (not so terrible as current compilers are not likely to put
single_ap in register anyway). On the other hand, single_ap can't be put in
STL container, can't be returned from the function, etc. Thus, the only its
possible use is ensuring that temporarily allocated object is deleted on
exception throw. (I would appreciate J.Kanze explaining the workarounds he
mentioned in another follow-up).

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

No offense intended, but what kind of argument is that? The entire C/C++
standard library (with the possible exception of the functions that
directly map to operating system calls) can (especially STL) be
reimplemented by each user - but what good will the standard then be?
I know the standards committee is doing a great and difficult job - but to
me such an attitude seems not very productive from the marketing point of
view.

              Best regards                    Genie

--
--------------------------------------------------------------------
Eugene V. Radchenko           Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ 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. ]

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!
             Cheers                    Genie

--
--------------------------------------------------------------------
Eugene V. Radchenko           Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ 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. ]

> ==========Steve Clamage, 1/17/96==========

[stuff deleted]

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

I do not see where either approach is always better.  Why is
one way given an easier time of it than the other?  I think
both semantics have real value and need to be part of the
standard arsenal to be used.  Having both major techniques
available (instead of making it a contest that throws out one
valuable technique) is the more desirable solution from the
customer view [even if it would work you guys to the bone].
That also seems more in the C++ style and philosophy.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.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 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 <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. ]