🚀 go-pugleaf

In article <4jucle$i41@bmtlh10.bnr.ca> "john (j.d.) hickin" <hickin@bnr.ca> writes:
...
>The January DWP continues to say that auto_ptr provides strict ownership
>semantics [20.4.5  Template class auto_ptr]:
>
>2 The auto_ptr provides a semantics of strict ownership.  An object  may
>  be  safely  pointed  to  by  only one auto_ptr, so copying an auto_ptr
>  copies the pointer and transfers ownership to the destination.
>
>The implementation you have quoted does not contradict the above statement.
>The January version of auto_ptr had the owner's stored pointer set to 0 so
>that dereferencing under such conditions was not allowed:
>
>X& operator*() const;
>
>  Requires:
>    get() != 0
>  Returns:
>    *get()
>
>A simple amendment to the DWP, perhaps already in the works, is all we require:
>
To my knowledge this is not "already in the works".
>
>X& operator*() const;
>
>  Requires:
>    owner == true
>  Returns:
>    *get()
>
>With change, dereferencing will, as before, be undefined when ownership is 
>not held.

Please remember that auto_ptr is designed to make sure that pointers are 
deleted when exceptions are thrown, not to be sure that already deleted
pointers are not misused.  The semantics of auto_ptr are intentionally
"as close as possible" to ordinary pointers: if you use a pointer that is
already deleted the behaviour is undefined, and the same for auto_ptr; if you
use a pointer that is owned by another object (i.e. will be deleted by that
objects destructor) the behaviour is well defined as long as the pointer
remains valid, and the same for auto_ptr; you cannot tell at runtime whether
a pointer is valid, and the same for auto_ptr.

What you can do is design your code so that you know who owns each object when.
The auto_ptr template can help you implement such designs safely.  If you
cannot design your code to work with auto_ptr you probably need garbage
collection of some form.

I do not forsee any fundamental changes in the auto_ptr design: its too late
and has taken too much work to get it where it is today.  The important issues
are whether it is completely and correctly specified, and whether any
necessary features are missing.  In particular:
   * Should auto_ptr have an operator-> ?  A proposal to add one was nearly 
     accepted at Santa Cruz, but was withdrawn when the prerequisite extension
     failed.
   * Should auto_ptr have an operator== ?
   * Should any of the auto_ptr functions have exception specifications?
   * Many of the requirements can be diagnosed at compile-time but are only
     specified to produce undefined behavior at run-time.  Should we tighten the
     specification?  If so, how?

Greg Colvin
gregor@netcom.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 
]