🚀 go-pugleaf

bgibbons@taligent.com (Bill Gibbons) writes:

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

You are right, my suggestion above wouldn't work.

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

So what do Taligent's auto_ptr-like classes do about the problem
that the assignment operator modifies its argument, but its argument
must be a const reference so that it can accept a temporary, such as
a function return value? 

I can see several options:

	(1) declare the assignment operator to take a non-const reference;
	    this is what the April draft does, but as James Kanze said, it
	    seems to make auto_ptr useless for returning values from functions.

	(2) declare the pointer field of auto_ptr as `mutable'

	(3) cast-away-const in the assignment operator
	    This is similar to using `mutable', but less safe,
	    since one day someone will try to use a genuinely
	    const auto_ptr, and the compiler will place it in ROM.

	(4) use an extra level of indirection

Now that you have pointed out the problem with my earlier suggestion,
and having considered the issue further, I think I must agree that
(mis)using `mutable' may be the best option.

Of course, there are a couple of other options:

	(5) don't use auto_ptr, use a reference counted pointer instead

	(6) use garbage collection! ;-)

-- 
Fergus Henderson             |  "Australia is the richest country in the world,

fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.
---
[ 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. ]