This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patch: <bits/localefwd.h> with -fno-exceptions

>>>>> "Mark" == Mark Mitchell <> writes:

> For me the key issues are:

>   - we should avoid user surprise, and 


>   - we should try to follow existing practice, except where we really
>     have a good reason not to do so.

> Existing practice is that most compiler's -fno-exceptions equivalents
> *do* expunge all of Chapter 15.

Out of curiosity, which compilers have you tried, other than EDG?  Do they
also disallow empty throw specs?

The purpose of the flag, from a user perspective, is to avoid the overhead
associated with exception handling.

Given that, if we see EH constructs while compiling, there are two possible

  1) The user is an idiot, and this code needs EH support, or
  2) The user either knows that no exceptions will actually be thrown, or
     intends to forego the ability to recover cleanly from an error.

Your position is that situation #2 can be handled without too much trouble
using macros, so we should assume situation #1 and give an error.

I suppose I can be convinced to agree with you about try/catch, but I still
strongly disagree about throw specs.

The only reasonable use of throw specs IMO is adding empty throw specs to a
function declaration to let the compiler know that the function in question
can't throw, for optimization.  We shouldn't complain about that usage with
-fno-exceptions.  Nor should we complain about people redefining ::operator
new with the appropriate throw specs.  I suppose we could complain about
other throw specs, but I don't see any compelling reason to do so; it's
simpler just to ignore them all.  Especially since that's the status quo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]