This is the mail archive of the libstdc++@gcc.gnu.org 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


>>>>> "Jason" == Jason Merrill <jason@redhat.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
    >> braces.

    Jason> Yes.  I actually think the SGI approach, namely __STL_TRY
    Jason> and __STL_UNWIND, is pretty clean and reasonable.

Yes.

    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:

  #define throw(x...)

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
more?)

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
getting burned.

IMO, of course. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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