From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-09 19:31:41
> I hadn't considered the destructor calling undecorated functions.
> Most of my destructors do simple cleanup and don't call any functions...
Except sub- and base-object destructors, implicitly.
> I don't understand your reasoning for why exception specifications
> deteriorates the separation of interface from implementation. The
> exception specification is part of the interface and just one more
> constraint that the implementation must adhere to. Like all
> constrains imposed by an interface, if the exception specification
> is too inflexible, this will cause problems for the implementation.
empty exception-specifications on destructors may be an exception to the
rule, but in general an exception-specification may restrict
interface-preserving changes you can make to the implementation of a
function during the normal course of maintenance. Since there is essentially
no compile-time enforcement of exception-specifications, it can be very
difficult to be sure that you haven't made a change which violates an
> To help future library users from reraising this issue, perhaps the
> rationale on the bottom of
> http://www.boost.org/libs/smart_ptr/smart_ptr.htm should be augmented
> to mention that the exception specification was omitted because the
> smart_ptr classes are designed to work with pointees that have
> undecorated destuctors. The current explanation: "Because there is no
> way to directly express this prohibition in C++, compilers would be
> forced to generated unneeded try/catch blocks if throw() was coded."
> makes it sound to me like if there was a way that a smart_ptr could
> cause a compile error if the pointee's destructor didn't have
> throw(), Boost would have done that.
Some have argued that C++ should work that way. I don't neccessarily agree.
> Also, the sentence "For functions which can throw std::bad_alloc, empty
> throw specifiers are not supplied." is confusing. Of course empty
> throw specifiers woundn't be supplied.
I think I made this argument earlier, but it didn't make it into the docs.
> The issue is why isn't
> throw(std::bad_alloc) specified. I believe all the functions that throw
> bad_alloc also contain a delete of the user's type. According to the
> discussion in this thread, this is a good reason for not having a throw
> specification. However, I'd say that the shared_ptr and shared_array
> constructors are exceptions (NPI) since they do their deletes within
> a catch block, and so an exception from the pointee destructor will call
> terminate anyway.
Incorrect. An exception thrown from within a catch block works (almost) just
except that a different exception object is thrown.
> A compiler can (or will someday be able to) realize
> that the constructor can't throw anything besides std::bad_alloc and
> so no additional wrapping is necessary.
And in the mean time you will pay for the extra data tables, at best.
Where's the advantage in using the exception-specification?
> The question that remains is what to do until the compilers get up to
> speed. I like the purity of coding what it should be and using macros
> or other hacks in the iterum. This has the advantage of allowing the
> people with good compilers to make use of the exception specifications,
> whereas losers like me with VC can keep it in "make it work" mode for
> a while.
The question is: why do you think using exception-specifications is "what it
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk