🚀 go-pugleaf

In article <4k4noe$igl@jabba.lehman.com> ajay@lehman.com (Ajay Kamdar)
writes:

|> In article <bill-0504961003150001@bgibbons.vip.best.com>,
|> Bill Gibbons <bill@gibbons.org> wrote:
|> >
|> >Transfer of ownership is not the end goal - the end goal is
|> >to make auto_ptr useful for the "resource acquisition is
|> >initialization" idiom.  That is very painful without transfer
|> >of ownership.
|> >
|> >In particular, if you want to do the resource acquisition in a
|> >function called by the function which needs to hold the resource,
|> >there is no good exception-safe way to pass the pointer from the
|> >callee to the caller.
|> >
|> >You can get close (at some cost in clarity):
|> >
|>        [ snip... ]

|> It is not clear at all that the copy semantics of auto_ptr
|> are essential for exception-safe transfer of resources.
|> The same example coded as follows does not use
|> the copy semantics of auto_ptr:


|>     extern X* get_X();   // returns a resource acquired
|> 			 // by the callee, to be deleted
|> 			 // by the caller.

|>     void f() {
|>         auto_ptr<X> ptr = get_X();
|> 			// resource allocated by get_X()
|>         ...
|>    }

|> And get_X() is not unnecessarily complicated either:

|>    X* get_X()
|>    {
|>       auto_ptr<X> p = new X;

|>       // ... stuff that could throw an exception

|>       // We got here. Means normal return.
|>       return p.release();
|>    }


|> What's wrong with this? It doesn't require copy semantics
|> for auto_ptr. Yet both the caller and the callee
|> are exception safe and there is no loss of clarity.

As Bill pointed out in a previous incarnation of this thread, `get_X',
as written above is *NOT* exception safe.  After the call to p.release,
the compiler will still cause all of the destructors of any local
variables (and any value parameters to the function) to be called.  If
any of these destructors throw an exception, you've lost p.  For good.

Now, I don't generally think it a good idea to let an exception
propagate out of a destructor.  But I don't think that a standard
auto_ptr class should require this sort of additional rule in order to
be useful.

Personally, I would have preferred to see auto_ptr set the pointer to
NULL when ownership was transfered, even though this meant having a
const parameter that wasn't.  But I consider the current version
acceptable, and if it is the compromise that is needed to obtain
consensus, I will go along with it.  (Although I wouldn't mind an
additional function to indicate whether I was owner or not.)

BTW: although I do not, nor never have, worked for Taligent, my
experience does parallel theirs.  So when comparing the number of people
in favor of the idiom, you have to count some of those involved in the
previous discussions, as well as those at Taligent.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]