🚀 go-pugleaf

In article <47616o$lvr@bcarh8ab.bnr.ca> "ian (i.) willmott" <willmott@bnr.ca> writes:

> Some recent comments in this newsgroup indicate that there is some
> problem with returning an auto_ptr from a function. I was not aware
> of this; the April 1995 working paper does not mention it and it is
> not obvious to me why there should be a problem other than the
> overhead of constructing and destroying a temporary object.

The problem is that the argument of auto_ptr's operator= and copy
constructor is a non-const reference, rather than a const reference.
(And that's entirely proper, since an expression like "p2 = p1" really
does modify p1; calling the argument of operator= a const reference
would be a lie.)

If a function returns an auto_ptr as an rvalue, it can't be used as
the argument to a function that expects a non-const reference.  There
are ways to get around this, but they're all a bit clumsy.

I don't know of any simply way to modify the definition of auto_ptr in
the standard to avoid this difficulty: it seems to follow from the
semantics of strict ownership.
-- 
  Matt Austern                             He showed his lower teeth.  "We 
  matt@physics.berkeley.edu                all have flaws," he said, "and 
  http://dogbert.lbl.gov/~matt             mine is being wicked."

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