🚀 go-pugleaf

In article <47l6im$qu1@watnews2.watson.ibm.com> jjb@watson.ibm.com
(John Barton) writes:

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

Put that way, it does sound crazy.  But I do it regularly with my
RefCntPtr class.  The temporary serves as a bridge between a local in
the called function (which has just gone out of scope), and a local in
the caller (which has yet to be initialized).  I would be interested
in hearing of examples where you have failed `to beat this game'.
Your statement worries me that there is a defect waiting to happen in
my own code.

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

This fails on two counts:

1. The actual service provider may be several layers removed.  In
particular, an intermediate function may be used to `garnish' the
new'ed object before returning it to the client.  And presumably,
garnishing it could cause an exception.

2. As Bill Gibbons has pointed out, there is a window of opertunity at
the end of the server function in which the object may be lost.  While
I think that most people would agree that it is not a good idea to let
exceptions escape from destructors, good code - at least good library
code - will be robust even in this case.
---
[ 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. ]