The code: #include <stdexcept> #include <string> class der1 : public std::exception { std::string s;}; int main() { der1 d; return 0; } gets you: ~/ootbc/common$ g++ foo.cc foo.cc:3: error: looser throw specifier for 'virtual der1::~der1()' /usr/include/c++/4.1.0/exception:58: error: overriding 'virtual std::exception::~exception() throw ()' I understand that the throw specification (an abortion in general IMO; why it was ever adopted after the experience with CLU is beyond me) of an overload in a derived class but be a subset of the specifications in the overloaded functions in the base class(es). However in the case of implicitly generated functions, requiring the user to explicitly say: ~der1() throw() {} in the derived class is just silly. It also introduces non-portable implementation dependencies where, as here, the base class is a system class with unknown and frequently changing throw specification that vary across hosts. Ivan
Comeau also errors and I don't have access to the standard right at this moment to double check. "ComeauTest.c", line 3: error: exception specification for implicitly declared virtual function "der1::~der1" is incompatible with that of overridden function "std::exception::~exception" class der1 : public std::exception { std::string s;}; ^ (In reply to comment #0) > It also introduces non-portable > implementation dependencies where, as here, the base class is a system class > with unknown and frequently changing throw specification that vary across To reply to this part, you are incorrect in saying they are unknown and changing throw specifications as the C++ standard defines them.
Fair enough w/r/t standard base classes if the standard does indeed define the throw specifications for each class's destructors. But the same dependency appears on any base class, whether standard, 3rd party, or locally written. That dependency is necessary for a destructor you actually write, but it's just silly to require it on the compiler generated ones. Can't the compiler generate the right throw specification? Ivan
(In reply to comment #2) > Can't the compiler generate the right throw specification? No because the C++ standard says it does but with respect to all functions it calls and not just the base class. 15.4/13: An implicitly declared special member function (clause 12) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, destructor, or copy assingment operator, is implicit exception-specification specifies the type-id T if and only if T is allows by the exception-specification of a function directly invoked by f's implicitly defintion; f shall allow exception if __any__ function it directly invokes all exceptions, and f shall no exceptions if __every__ function it directly invoked allows no exceptions. (emphisis is mine).