Article View: comp.std.c++
Article #2409Re: auto_ptr<T> as function return type
From: James Kanze US/ESC 60/3/141 #407...
Date: Fri, 03 Nov 1995 12:12
Date: Fri, 03 Nov 1995 12:12
74 lines
3365 bytes
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!MattReferences:
<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