In article <IbNt2.16100$202.7965476@news1.teleport.com>,
  "Scott Meyers" <smeyers@aristeia.com> wrote:
>
>
> <psu22377@odin.cc.pdx.edu> wrote in message news:7979gr$b13
$1@nnrp1.dejanews.com...
> >
> >I am confused about auto_ptr semantics.  I have read the comp.std.c++ FAQ and
> >I believe it contradicts the C++ ISO/IEC 14882 first edition standard
> >1998-Sep- 01, with regard to copy construction and assignment.
>
> As fate would have it, I just recently updated the auto_ptr information at
> my More Effective C++'s web site.  For what I believe to be a good
> description of the current status of auto_ptr, along with how auto_ptr got
> to be the way it is, check out
> http://www.awl.com/cseng/titles/0-201-63371-X/auto_ptr.html.
>
> Scott
>
> Scott Meyers, Ph.D.                  Voice: 503/638-6028
> Author:  Effective C++ CD            Fax:   503/638-6614
>          Effective C++               Email: smeyers@aristeia.com
>          More Effective C++          WWW:   http://www.aristeia.com/


Thanks!  Indeed your description of the auto_ptr and its history is the
singluar clearest and most thorough I have read.  thanks for putting that
together.

Your page confirms that auto_ptr as currently described in the FAQ section C
item 2 for this group is indeed out of date in this respect:

-auto_ptr copy constructor/assignment take NON-const references to auto_ptrs,
and both null out the rhs auto_ptr (FAQ currently claims const references, w/o
nulling rhs auto_ptr - this is the CD-2 version, not the current version)

The information on your page from Bill Gibbons and Greg Colvin
<greg@imrgold.com> is also the clearest explanation of how auto_ptr semantics
use auto_ptr_ref to allow for case like the one below to work:

auto_ptr<int> source();
void sink( auto_ptr<int> );
main()
{
   sink( source() );
}

It was an exhaustive explanation of how auto_ptr_ref and conversion functions
allow the above idiom to occur.

thanks
psu22377@odin.cc.pdx.edu

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I am confused about auto_ptr semantics.  I have read the comp.std.c++ FAQ and
I believe it contradicts the C++ ISO/IEC 14882 first edition standard
1998-Sep- 01, with regard to copy construction and assignment.

According to the C++ standard, 20.4.5.1 auto_ptr constructors/assignment are
defined:

template<class Y> auto_ptr(auto_ptr<Y> & a) throw();
template<class Y> auto_ptr& operator=(auto_ptr<Y>& a) throw();

both of which call a.release() in the process.  release() is defined in
20.4.5.2 to return the pointer held by *this and that *this will then hold the
NULL pointer.  This to me means that copy construction/assignment of one
auto_ptr to another will null out the auto_ptr being copied from or assigned
from.  Also note that copy construction and assignment signatures do not take
const auto_ptr's i.e. they modify the object from which they are being copied,
and could not therefore be chained as in the example from comp.std.c++ FAQ:
   auto_ptr<T> source();
   void sink(auto_ptr<T>);


According to the comp.std.c++ FAQ, located at:
http://reality.sgi.com/austern/std-c++/faq.html BEGIN QUOTE:"  void g() {
auto_ptr<T> p(new T);  f(p.get());  } The auto_ptr class was originally
designed to handle this sort of idiom. Later, partly because of experience at
Taligent, it was decided to support two other idioms:

   auto_ptr<T> source();
   void sink(auto_ptr<T>);
Functions like source() return an auto_ptr that the caller will destroy, and
functions like sink() take an auto_ptr that the callee will destroy.
Some sort of assignment semantics is necessary if the source() and sink()
idioms are to work; what should the semantics be? If p1 and p2 are auto_ptrs,
then p1 = p2 causes p1 to delete the object it points to, if any, and take
ownership of the object pointed to by p2. What happens to p2? It might be nice
to invalidate p2, so that p2.get() would return 0, but that would imply that
the assignment operator would be

  auto_ptr& auto_ptr::operator=(auto_ptr& in_out); instead of  auto_ptr&
auto_ptr::operator=(const auto_ptr& in); which would further imply that
auto_ptr<T> p(source()) would be ill formed. What to do? We could have made
the pointer held by auto_ptr mutable, but having a supposedly const operation
change the public value of an object was distasteful. Instead we decided that
the pointer held by p2 would not be changed (that is, normal copy semantics),
but that p2 would no longer own the object it pointed to, and would therefore
not delete it when p2 goes out of scope. In this model, the ownership of a
pointer is not part of the public value of the auto_ptr, and therefore
auto_ptr has no test for ownership.

An ownership test is unnecessary in the idioms auto_ptr was designed to
support, so the lack of such a test is not a defect. If you need to use
something other than those idioms then auto_ptr will probably not work for
you anyway: you probably need a reference-counted pointer class instead, or
perhaps a general purpose garbage collector. " END QUOTE

These two definitions seem contradictory.  If they are not contradictory, can
someone explain the semantics to me more clearly?  If they do contradict,
which one correctly describes the proper behavior for auto_ptr?  if
comp.std.c++ is correct and the standard is wrong, is anyone maintaining a
publicly accessible list of errata for the c++ standard?


thanks for any assistance in this matter.
-mike <psu22377@odin.cc.pdx.edu>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<psu22377@odin.cc.pdx.edu> wrote in message news:7979gr$b13$1@nnrp1.dejanews.com...
>
>I am confused about auto_ptr semantics.  I have read the comp.std.c++ FAQ and
>I believe it contradicts the C++ ISO/IEC 14882 first edition standard
>1998-Sep- 01, with regard to copy construction and assignment.

As fate would have it, I just recently updated the auto_ptr information at
my More Effective C++'s web site.  For what I believe to be a good
description of the current status of auto_ptr, along with how auto_ptr got
to be the way it is, check out
http://www.awl.com/cseng/titles/0-201-63371-X/auto_ptr.html.

Scott

Scott Meyers, Ph.D.                  Voice: 503/638-6028
Author:  Effective C++ CD            Fax:   503/638-6614
         Effective C++               Email: smeyers@aristeia.com
         More Effective C++          WWW:   http://www.aristeia.com/




[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]