🚀 go-pugleaf

Stein Somers writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>: 	auto_ptr<double> p(f().release());
>: 	p.reset(f().release());
>
>This has been mentioned earlier, of course.  So I'd like to repost
>this recent uncountered reply:
>
>Eric Biederman (ebiederm@cse.unl.edu) wrote:
>: 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).

What makes you think an exception will be thrown in this case?

The draft standard certainly doesn't require implementations to
throw an exception if they run out of stack space, and I don't
know of any implementations that do so.

In any case, exactly the same problem could occur inside the
copy-constructor or assignment operator for auto_ptr! 
So your example doesn't seem to show any reason against using
release().

If there really was a problem with using release(), we could
go back to the earlier suggestion of using a transfer() function
which returned an enapsulated pointer.

>: There are probably more realistic examples is less mundane code.

I remain unconvinced.

>Maybe when an object containing many auto_ptr's is returned, in which
>case the auto_ptr's must be moved jointly?

Anything wrong with just returning an auto_ptr to a dynamically 
allocated object (containing many auto_ptrs), rather than returning
it by value?

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ 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. ]