kanze@gabi-soft.fr (J. Kanze) writes:

>Actually, it occurs to me that the following does work:
>
>    auto_ptr< T >       f() ;
>    auto_ptr< T >       p1( f().release() ) ;
> auto_ptr< T >  p2 ;
> p2.reset( f().release() ) ;
>
>Somehow, it just doesn't seem natural, though.

It seems fine to me.

It certainly seems more natural than assignment operators that
clobber the right-hand operand.

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

Someone writes:
   >Actually, it occurs to me that the following does work:
   >
   >    auto_ptr< T >       f() ;
   >    auto_ptr< T >       p1( f().release() ) ;
   > auto_ptr< T >  p2 ;
   > p2.reset( f().release() ) ;
   >
   >Somehow, it just doesn't seem natural, though.

There is a case where it doesn't work.

The problem is that you are passing it as a standard pointer type.
What happens if you were to run out of stack after the call to release
and before the call to the constructor, or reset.  And an exception is
thrown.

If your program actualy catches that exception then a memory leak has
occured. ( A rare case I will admit).

There are probably more realistic examples is less mundane code.

It must be in an object at all times TO BE SAFE!
---
[ 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. ]

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

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> 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?

You left out the best solution in your list that followed this.  The best
solution would be to get rid of the worse-than-useless restriction that
prevents non-const references to temporaries.

The intent of that rule is to prevent code that thinks it's calling a function
that modifies an object passed as an argument, when in fact it's modifying a
temporary produced by an implicit conversion of that object to the argument
type.

The rule should be replaced by one that better accomplishes the intent: There
should simply be no implicit conversion -- T::T(S) or S::operator T() -- of a
temporary of type S to a non-const reference to T.  Temporaries themselves
can be modifiable!

I quote the rest of fjh's lousy solutions (hey, he admits it) for reference:

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

> 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! ;-)
---
[ 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. ]