Maarten Hilferink <Maarten@geodan.nl> writes:

>In the FAQ of this group
>(http://reality.sgi.com/austern/std-c++/faq.html)
>FAQ C2:."Why is auto_ptr defined the way it is? What problem is it
>supposed to solve?",
>it seems to be assumed that auto_ptr does meet the CopyConstructible
>restrictions,
>since it basically says that after the Taligent experience, it was
>decided to
>support two other idioms, requireing a const constructor and const
>assignment operator.
>I notice that this view is inconsistent with the WP(Jan96).

The working paper has been changed since Jan96.

>Is this decision/proposal towards CopyConstructibleness of auto_ptr
>still on the agenda?

No -- it's already been done.

>If so, it has my support.It requires only a:
>1. changed signature of:
>   a.  template <class U> auto_ptr(const auto_ptr<u>& source);
>   b.  template <class U> operator =(const auto_ptr<u>& source);
>2. changed specification of:
>   a.  T* release() const;
>       Postcondition: get() still gives the same value
>   b.  void reset(T* p=0);
>       Effects: deletes get() if get() != p AND the ownee was not
>released, else nothing
>3. Implementations of auto_ptr would require an extra private member to
>indicate ownership-status

1, 2a, and 3. have been done.  Regarding 2b, the `reset()' member
has been removed.

(Incidentally, implementations of auto_ptr can use non-portable
such as tagging the bottom bit of pointers to avoid any space
overhead for 3.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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
]