Re: std::auto_ptr as exception object
* j.l.olsson@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.
It was explained to me that a possible problem case is:
try {
throw std::auto_ptr<int>(new int(10));
} catch (std::auto_ptr<int> a)
{
throw;
}
Yes, in this case the re-throw throws a std::auto_ptr where the embedded raw
pointer is null.
If I understood correctly, the re-throw would use the original
exception object, which has lost ownership.
Yes.
Is there a way to prevent catching by value?
Not for exception handling.
Is catching by reference kosher?
Yes, but that does not mean std::auto_ptr is kosher as exception object.
Are there other problems with throwing auto_ptrs?
Possibly. :-)
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?