🚀 go-pugleaf

In article <9527400.19710@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) wrote:

> I don't think so.  Instead of returning an auto_ptr<T>, you can
> just return the T* obtained from a call to auto_ptr<T>::release().
> The caller can use this T* to initialize another auto_ptr<T>.

This is very risky.  The whole point of auto_ptr is that it makes code
which handles allocated objects behave well when exceptions propagate
through the scope using the pointer.  To make this work well there are
two very strict requirements:

   * The raw pointer must *always* be owned by some auto_ptr.

   * The raw pointer must *never* be owned by more than one auto_ptr.

Any time you discard the auto_ptr and pass around the raw pointer you
violate the first requirement.  Any time you initialize an auto_ptr with
a raw pointer which belongs to another auto_ptr you violate the second
requirement.

For example:

    struct X { ~X() { throw "oops!"; } };

    T * unsafe_function() {
        auto_ptr<T> p = new T;
        X x;
        return p.release();
    }

Sequence of events:

  (1) The pointer is released, making the function vulnerable.
  (2) "x" is destroyed, causing an exception to be thrown.
  (3) "p" is destroyed, but "p" no longer holds the pointer.
  (4) "unsafe_function" exits with a memory leak.

The interesting cases for assignment and initialization are not uses of
local variables in the same scope, but rather passing arguments to
functions and returning values from functions.  In these contexts it is
necessary to either violate the above requirements (in which case the
program isn't exception-safe) or deal with transfer of ownership directly
in the assignment operator and copy constructor.

Taligent has had years of experience using a variety of templates which
are variants of auto_ptr.  The consensus here is that auto_ptr must have
ownership semantics, and they must be enforced by the assignment operator
and copy constructor.

-- 
Bill Gibbons
bgibbons@taligent.com

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