Re: std::auto_ptr as exception object
* ejstans:
{ Multi-posted article. -mod }
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 problem is:
try {
throw std::auto_ptr<int>(new int(10));
} catch (std::auto_ptr<int> a) {
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?
Over in clc++, where you multi-posted this article, James Kanze pointed out that
the throw expression in the above code is an rvalue; an rvalue can't be bound to
the formal argument in a T(T&) constructor; for throw a copy constructor must be
accessible as if that copy constructor was called; and non-const argument T(T&)
is all that poor std::auto_ptr has in the way of copy constructors.
Hence the code shouldn't even compile.
Unfortunately some current compilers, with all-too-clever implementations of
std::auto_ptr, do compile the code (although MSVC issues a warning).
Also, over in clc++, where you multi-posted this article, I pointed out that
it's clearly the intention of the standard that all exception objects should be
copy constructible, and that you should regard it as an error to throw an object
that isn't copy constructible (std::auto_ptr isn't copy constructible).
Unfortunately that implicit requirement isn't spelled out anywhere, AFAICS.
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?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]