This is the mail archive of the
mailing list for the libstdc++ project.
Re: patch: <bits/localefwd.h> with -fno-exceptions
>>>>> "Jason" == Jason Merrill <email@example.com> writes:
>> There are other approaches. For example,
>> #if NO_EXCEPTIONS #define try if (true) #define catch(x) if
>> (false) #endif
>> This works because try and catch blocks are always enclosed in
Jason> Yes. I actually think the SGI approach, namely __STL_TRY
Jason> and __STL_UNWIND, is pretty clean and reasonable.
Jason> Me, too, actually. I started to loudly disagree, and then
Jason> thought about it some more.
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.
Since we agree it's easy to use macros to handle try/catch blocks,
(including the variant I gave that doesn't require chaning your source
at all), I don't see that we need to do much about try/catch blocks.
Throw specs are a different issue, because you do have to do the
PARAMS style double parenthesization to get things to work out right,
so you really do have to change your source, no matter how many macros
you play with.
Oh, wait, I guess you can use varargs macros:
So, you can do it all with macros.
I don't like the idea of silently changing programs in this way. One
problem is that we have no way of enforcing consistency across .o
files. If you comiple a library with -fexceptions, and I link with
it, but compile the headers/inlines with -fno-exceptions gobbledygook
is the likely result. (This is true of lots of options, but why add
Imagine that the rocket-launching software depends on an
unexpected-handler in the case of throw-specs, or a catch block
firing. I'd like someone who understands the source to have to
explicitly say "yes, that's OK, you can just diable all that gunk".
In that case, turn on the macros (mine, if you're lazy, the clearer
SGI variants if you're not), and you're all set.
I just don't see any compelling need for compiler support here. It's
not like -fno-strict-aliasing which is necessary to deal with old, but
now incorrect, code. All the compiler magic would do is save
programmers who know what they're doing the cost of a few macros, and
at the expense of programmers who are less experienced potentially
IMO, of course. :-)
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com