🚀 go-pugleaf

In article <199509111753.AA15077@xs1.xs4all.nl> veldhuis@xs4all.nl writes:
>:>What follows are my best guesses for the definitions of the operator=
>:>and reset functions:
>:>
>:>  template<class T>
>:>  class auto_ptr {
>:>  public:
>:>    void operator=(auto_ptr<T>& rhs);
>:>    T * reset(T *p = 0);
>:>    ...
>:>  
>:>  private:
>:>    T *pointee;
>:>  };
>:>  
>:>  template<class T>
>:>  inline void auto_ptr<T>::operator=(auto_ptr<T>& rhs)
>:>  { if (this != &rhs) reset(rhs.release()); }
>:>
>:>  template<class T>
>:>  inline T* auto_ptr<T>::reset(T *p)
>:>  {
>:>  	delete pointee;
>:>  	return pointee = p;
>:>  } 
>:>
>:>Questions:

What to do when this==&rhs is still an open issue for the committee. Also,
reset() is supposed to return void, and operator= is supposed to return *this.
(despite what the draft working paper says, which is wrong and will be fixed)

>Sorry, I have no answers for that. I do have another question/remark.
>The way the auto_ptr assignment is setup does have very different semantics 
>from all other assignments I know in that the previous value becomes invalid 
>after the assignment. Assume :
>
>auto_ptr<int> a, b;
>
>*a = 10;  // Set a to 10.
>b = a;    // Set b also to a (10), but deletes a in the process ?

No, the int pointed to by a is not deleted, but is now owned by b, and
*a == 0, that is, a owns nothing.

>cout << *a;  // crash ??? since a is no longer valid ?
>

Yes, *a above has undefined behavior. ,Note that since *0 is undefined
behavior an implementation is free to do anything, including something
helpful like stopping in a debugger or throwing an exception.
>
>It seems to me that in the assignment a deep copy should be performed in 
>stead of a binary copy.

That would require that the type being pointed to have a copy constructor.
If you wish you can write b.reset(new int(*a)) instead of b = a.

>I could be wrong when auto_ptr::release() does only set a flag that its 
>pointer still is valid, but it is no longer the owner of the memory pointed 
>to. In this case however the implementation of reset would be erroneous since 
>that would have to test that flag also. The only correct way of implementing 
>this that I can think of would be to use reference counting on the 
>pointee. 

The whole point of auto_ptr is to enforce a disciple of strict ownership: there
is only one owner of the object pointed to by an auto_ptr, and ownership is
transferred by copying the auto_ptr. Reference counting or garbage collection
would be necessary to provide shared ownership, but the committee carefully
considered and rejected all of my proposals for shared ownership. Strict
ownership is a strict discipline, but it appears to be the simplest and most
efficient semantics that can solve the problem of exception-safe memory
management.

[ Greg Colvin wrote the original auto_ptr proposal, and worked through
  many revisions until it was finally accepted by the C++ committee. -- sdc ]

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