* ejstans:
> { Multi-posted article. -mod }
>
> Hello,
>
> I am using std::auto_ptr to try to keep owner****p 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 owner****p.
> 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! ]
|
