🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2409

Re: auto_ptr<T> as function return type

#2409
From: James Kanze US/ESC 60/3/141 #407...
Date: Fri, 03 Nov 1995 12:12
74 lines
3365 bytes
In article <47b1um$fvs@infoserv.rug.ac.be>
uunet!PROBLEM_WITH_INEWS_GATEWAY_FILE!somers@ncar.UCAR.EDU (Stein
Somers) writes:

|> Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
|> : Yep.  With the current spec., you need to write

|> : 	auto_ptr<double> p(f().release());

|> : and

|> : 	p.reset(f().release());

|> : instead.

|> 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).
|> : 
|> : There are probably more realistic examples is less mundane code.

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

Very good point.  Having a copy constructor which takes a non-const
parameter means that in any object which contains (or inherits from)
an auto_ptr:

1) The compiler generated copy constructor will also have a non-const
parameter (as will the compiler generated assignment operator).  This
means that if you do not provide a copy constructor/assignment
operator yourself for your class, it `inherits' the problems of
auto_ptr with regards to being used as a return value.

2) If you wish to provide your own copy constructor/assignment
operator, either you declare the parameter non-const (with the
inherent problems), or you are forced to cast away const in your
function in order to transfer ownership.

|> : It must be in an object at all times TO BE SAFE!

|> Any remarks, please?

I fully agree with the above statement.  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.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung




---
[ 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. ]
Technical Details
Message-ID: <9511030943.AA23251@lts.sel.alcatel.de>
Path: arc1-ca.pugleaf.net!library.ucla.edu!agate!agate!Matt
References: <47616o$lvr@bcarh8ab.bnr.ca> <VANDEVOD.95Oct31222003@juicer.cs.rpi.edu> <9530600.21749@mulga.cs.mu.OZ.AU> <47b1um$fvs@infoserv.rug.ac.be>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!library.ucla.edu!agate!agate!Matt
From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
Newsgroups: comp.std.c++
Subject: Re: auto_ptr<T> as function return type
Date: 03 Nov 1995 12:12:00 GMT
Organization: <none>
Approved: Matt@physics.berkeley.edu
Message-ID: <9511030943.AA23251@lts.sel.alcatel.de>
References: <47616o$lvr@bcarh8ab.bnr.ca> <VANDEVOD.95Oct31222003@juicer.cs.rpi.edu> <9530600.21749@mulga.cs.mu.OZ.AU> <47b1um$fvs@infoserv.rug.ac.be>
NNTP-Posting-Host: austern.hip.berkeley.edu