Boost logo

Boost :

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2002-08-16 10:23:59

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> What resources are leaked? Of course I'm making a big assumption about how
> the compiler behaves under the hood, but, since it clearly _has_ to create
> duplicate instance of an exception that is thrown, on the heap, there is
> other way it would implement the exception.

HAS to? I think not.

A) the compiler doesn't HAVE to make a copy of the exception at all. For
example, if your code were compiled with MSVC, the exception object will
most likely be allocated in the stack of the throwing thread (and NOT copied
at all). Even if the implementation does copy it, there's nothing in the
standard that says it copies it into an object allocated from the heap
(indeed, such an implementation would be foolish, since heap exhaustion
causes an exception throw).

B) What resrouces? Who knows! The point is, the implementation is free to
have allocated anything it wants to between the throw point and the catch
point, and the implementation is responsible for freeing those resources -
when (and only when) the exception is handled via a normal exit from a catch

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> Would a runtime analyzer like Rational Purify, etc, detect a leak if there
> was an implementation that didn't take the assumed path? If so, the
> can be proven unequivocally to either work or not work. Yes from a
> standpoint, it is mal-formed code, but not from a practical perspective.

There's no telling. Any resources allocated by the implementation during
throw -> catch processing are outside the bounds of the C++ language
definition. They may not even be allocated by mechanisms that are
accessible outside the exception propagation mechanism.

You can make your technique portable by copying the exception onto the heap
yourself in the catch clause, but since std::exception doesn't define a
virtual clone() member, such copying will be problematic at best.


Boost list run by bdawes at, gregod at, cpdaniel at, john at