470,626 Members | 2,103 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,626 developers. It's quick & easy.

std::auto_ptr as exception object

Hello,

I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...

It was explained to me that a possible problem case is:

try {
throw std::auto_ptr<int>(new int(10));
} catch (std::auto_ptr<inta)
{
throw;
}

If I understood correctly, the re-throw would use the original
exception object, which has lost ownership.
Is there a way to prevent catching by value?
Is catching by reference kosher?
Are there other problems with throwing auto_ptrs?

Thanks.
Jun 27 '08 #1
7 1838
j.********@gmail.com wrote:
Hello,

I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...
Why on Earth would you want to?

--
Ian Collins.
Jun 27 '08 #2
On 28 Apr, 09:29, Ian Collins <ian-n...@hotmail.comwrote:
j.l.ols...@gmail.com wrote:
Hello,
I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...

Why on Earth would you want to?
Use auto_ptr or throw exceptions containing them?
Well, for the latter, kind of for the same reason one would want to
pass them as functions parameters I suppose?

In my case, let's say I have an auto_ptr'ized Msg object. Depending on
certain conditions it will be passed to different methods to do
various operations on it, and if successful it will be sent off to
other places and won't be of concern anymore. But if failure occurs
for some reason, the idea was to throw an exception and catch this in
the original place so that a different method can have a go at it.
Because of auto_ptr's ownership policy, somehow the Msg must also be
passed back. I thought it desirable to keep it auto_ptr'ized, but then
I realized there is cause for concern of putting the auto_ptr in the
exception...
Jun 27 '08 #3
Hi!

j.********@gmail.com wrote:
I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...

It was explained to me that a possible problem case is:

try {
throw std::auto_ptr<int>(new int(10));
} catch (std::auto_ptr<inta)
{
throw;
}

If I understood correctly, the re-throw would use the original
exception object, which has lost ownership.
Is there a way to prevent catching by value?
} catch (const std::auto_ptr<int>& a)

Is catching by reference kosher?
Yes.
Are there other problems with throwing auto_ptrs?
Besides the fact that it does not make sense? - Not that I know.

The lifetime of an exception object is managed by the compiler. You need
not to bother about that.
In your case
throw 10;
would do the job too. The same applies to almost any exception class.

Simply do not write throw new..., that's a job for Java programmers. And
I also recommend to receive constant function arguments by reference if
their copy-constructor is more complex than that of a built-in type.
That applies also to exception arguments.
Marcel
Jun 27 '08 #4
On Apr 28, 9:19 am, j.l.ols...@gmail.com wrote:
I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must
provide a copy constructor, which made me uncertain of the
soundness of throwing std::auto_ptrs...
It was explained to me that a possible problem case is:
try {
throw std::auto_ptr<int>(new int(10));
} catch (std::auto_ptr<inta)
{
throw;
}
If I understood correctly, the re-throw would use the original
exception object, which has lost ownership.
Is there a way to prevent catching by value?
Is catching by reference kosher?
It's the usual practice, since it takes polymorphism into
account.
Are there other problems with throwing auto_ptrs?
Well, the copy constructor takes a non-const reference, so you
cannot copy a temporary. (In other words, your example
shouldn't compile---although I couldn't find a compiler which
rejects it.)

The usual practice would be to throw by value, and catch by
const reference:

try {
throw 10 ;
} catch ( int const& err ) {
throw ;
}

(Of course, you almost never throw int's. In practice, you'd
throw some specific class derived from std::exception.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #5
On 28 Apr, 12:41, "Alf P. Steinbach" <al...@start.nowrote:
* j.l.ols...@gmail.com:
Hello,
I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...

It's clearly the intentention of that standard that an exception object must be
copy constructible. For example, §15.3/1 tells us that if a handler declares a
non-const exception object, changes to that object do not affect the temporary
that was created by the throw statement. While the copy constructible
requirement is (unfortunately) not spelled out, you should simply regard it as
an error to throw any object that is not copy constructible.

std::auto_ptr is not copy constructible.

And this causes MSVC 7.1 to emit a spurious warning when throwing a
std::auto_ptr, which warning should be taken very very seriously.
Thanks. This kind of answer was exactly what I was hoping for, and
I've banished
auto_ptr from my exception object.
Jun 27 '08 #6
Alf P. Steinbach wrote:
* j.********@gmail.com:
>Hello,

I am using std::auto_ptr to try to keep ownership of resources
straight. However, I became aware that exception objects must provide
a copy constructor, which made me uncertain of the soundness of
throwing std::auto_ptrs...

It's clearly the intentention of that standard that an exception object
must be
copy constructible. For example, §15.3/1 tells us that if a handler
declares a non-const exception object, changes to that object do not
affect the temporary that was created by the throw statement.
[snip]

You might be right about the intention of the standard, but I am not
convinced by that example. To me, it appears more likely that this
provision aligns catch-syntax and function call syntax. The same clause
says that if you catch by non-const reference, changes to the object will
be reflected in the original temporary. It seems that no copied of thrown
object will be created if you always catch by non-const reference.
Best

Kai-Uwe Bux
Jun 27 '08 #7
On Apr 30, 12:50 am, "Alf P. Steinbach" <al...@start.nowrote:
* Kai-Uwe Bux:
The throw itself copies, via copy constructor (but the problem
is that "copy constructor" can be T(T&), thus not excluding
auto_ptr & like classes).
But that does mean that you can't throw a temporary auto_ptr.
The original example was:
throw std::auto_ptr< T >( new T ) ;
(or something like that), the std::auto_ptr here is an rvalue,
and cannot be bound to a non-const reference.

(For the rest, I think you're totally right that the intent is
clearly that anything thrown be copiable---or CopyConstructible,
as the library parts of the standard call it.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by SerGioGio | last post: by
2 posts views Thread by Jamie Burns | last post: by
10 posts views Thread by ma740988 | last post: by
20 posts views Thread by Bronek Kozicki | last post: by
1 post views Thread by Guido Forthofer | last post: by
8 posts views Thread by Marchello | last post: by
10 posts views Thread by dragoncoder | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.