In article 4i4@kelly.teleport.com, smeyers@teleport.com (Scott Meyers) writes:

>The fact that there is so much controversy surrounding the semantics of
>auto_ptr imples to me that perhaps it should not be part of the standard
>library, but I am not on the standardization committee, so I was not
>present when the various pros and cons were discussed.  In the past,
>whenever I've asserted that the standardization committee made a "clearly
>dumb" decision, others with more information have shown me that the
>decision might not have been one I'd agree with, but it was not "dumb."  I
>suspect the same is true in this case, where I can't imagine the committee
>didn't consider the advantages of omitting auto_ptr and just letting
>everybody write their own variants.

Thanks for giving us the benefit of the doubt. :-)

A common line of reasoning in the committee goes like this: Feature X is
so simple that every programmer can whip up a version almost without having
to think about it; why put it in the standard? Well, X is so broadly useful
that every programmer will indeed whip up a version of it. In a program worked
on by different programmers, the versions will be slightly different, slightly
incompatible. Since the programmer "almost doesn't have to think about it"
some whipped-up versions will be slightly wrong. That's why we have a
standard library: it contains broadly useful items with standard syntax
and semantics that all programmers can rely on.

Initially, auto_ptr seemed uncontroversial and seemed to fall squarely in the
middle of the above line of reasoning. A companion proposal for a "counted
pointer" was also discussed. It was not adopted because although generally
useful, the committee felt that there are so many design tradeoffs in
a reference-counted class that no one solution was going be appropriate in
enough situations to make it worthwhile as a standard library item.

Later, differences of opinion on the proper semantics of auto_ptr emerged.
One possibility would be to say, "Oh, well, it's counted_ptr all over
again, let's drop it." Instead, the committee still thinks auto_ptr is
so useful it ought to be in the standard library, and we hope to agree
on semantics which will be considered adequate by nearly everyone.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4ov1qj$3iq@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>A companion proposal for a "counted pointer" was also discussed. It was not
>adopted because although generally useful, the committee felt that there are
>so many design tradeoffs in a reference-counted class that no one solution
>was going be appropriate in enough situations to make it worthwhile as a
>standard library item.

I have a high degree of respect for the efforts of the standard
committee, and a sincere appreciation for the thoughtful and competent
way they have addressed the issues.  However, I wish there was a way to
standardize the "counted pointer" concept.  I find that extremely useful
in my work.  It would be very nice if there was a standard
implementation on which I could rely.  Has someone cataloged the design
tradeoffs in a discussion I could find online?  I would probably find
consideration of the issues useful in refining my own implementation.
If this is not available, would anyone be interested in providing a
summary here?

--
Randy Oxentenko           | It is foolish to criticize.  There is little
rdo@elt.com               | point in fretting over the fact that God has
Opinions are my own.      | not seen fit to distribute evenly the gift
I don't speak for ELT.    | of intelligence.           -- John Wanamaker
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <9606041341.AA28108@mailhub.elt.com> rdo@elt.com (Randy Oxentenko) writes:

   implementation on which I could rely.  Has someone cataloged the design
   tradeoffs in a discussion I could find online?  I would probably find
   consideration of the issues useful in refining my own implementation.


You might want to try ftp://ftp.best.com/pub/edelson/papers/ede_us92.ps

- Ed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]