🚀 go-pugleaf

In article <9511030943.AA23251@lts.sel.alcatel.de>, James Kanze US/ESC 60/3/141
 #40763 <kanze@lts.sel.alcatel.de> writes:
|> [delete some stuff]
|>                                    ...   The whole point of auto_ptr
|> is that the object is put into an auto_ptr immediatly after creation,
|> and is in an auto_ptr at all times.  Any tricks involving removing it
|> from one auto_ptr, and later putting it in another, are just that:
|> tricks, and introduce an element of danger.  The purpose of auto_ptr
|> is precisely to eliminate this danger.

  Nicely put.  Strict ownership is fundamentally incompatible with
auto_ptr<T> as function return type.  The latter implies ownership
by the returned temporary: lifetime control by a temporary is craziness.
(I have tried to beat this game myself several times).

   The way to use auto_ptr<T> successfully is to limit it to client
code.  Service providers write:
   // Callers own the lifetime of returned object; pick it up in an auto_ptr.
   Foo* doWorkAndCreateAFoo();
Clients pick up the result in auto del pointers:
   auto_ptr<Foo> my_foo(doWorkAndCreateFoo());
Anyone who fails to read and heed the comment loses.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
	<http://www.research.ibm.com/xw-SoftwareTechnology>
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598
---
[ 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. ]