------- Comment #3 from igodard at pacbell dot net 2005-10-09 00:37 -------
OK, I see what is going on now. Here's a simple case:
#include <string>
class syntaxNoError : public std::exception {
std::string message;
};
which gets you:
scanner.cc:2: error: looser throw specifier for `virtual
syntaxNoError::~syntaxNoError()'
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/exception:56:
error: overriding `virtual std::exception::~exception() throw ()'
The problem is that std::exception has a "~exception() throw()" throw
specification on its descrictor, whereas the std::string member does *not* have
a throw spec on its destructor. Consequently the compiler (rightly) complains
that the (virtual) implicit destructor could throw, courtesy of std::string.
This leaves us with two problems. The first is that the diagnostic in the
original test case gives a bogus line number. The second is that the throw spec
on ~std::exception in the library prevents any derived exception heirarchy from
using any structure much richer than POD, because it's generally agreed that
throw specs are a Really Bad Idea, but any member with a destructor but no
throw spec will get this problem.
Throwing destructors are generally agreed to be unrecoverable anyway I think,
so the throw spec (like most throw specs) just gets in the way of reuse and
will formce me to use reinterpret casts to get around the nuisance.
I'm sure the bogus line number counts as a gcc pproblem. Who do I take the
spurious throw spec to? (i.e. where's the bugzilla site for glibc++?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24280
