[boost] Re: Misc library documentation issues

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
exception-specification.

> 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
like writing
 throw;
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
should be"?

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications