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

[Phil Edwards]

On Thu, Jan 18, 2001 at 07:37:33PM -0800, Benjamin Kosnik wrote:
> 
> ...Oh wait. there are no comments describing this flag. Whoops. What is it 
> supposed to do, anyway?

I was about to ask that...


Mark wrote:
> It's just a fact of
> life in C++ that if you want to go to an exception-free model, you
> have to macroize your code somewhat heavily.

Some facts of life suck.  This is one of them.  I think we should do
what we can to improve the facts.


And Benjamin wrote:
> Code that depends on real exceptions being throw will fail regardless of 
> the proposed  -fno-exceptions behavior. 

This is why I think we'd be safe.  If users write code involving exceptions,
they will need to compile with -fexceptions to get what they want, period.

Users writing code for exception-free environments should be able to tell
the compiler "no exceptions" and not be surprised when the library suddenly
starts tossing exceptions about.  I would much rather get some help from
the compiler in that respect than to load the library down with macros.


As far as impact on user code instead of library code, here's my rambling:

If we make -fno-exceptions perform transformations like

    try -> if(true)
    catch -> if(false)
    throw -> abort  OR
    throw -> func   when "-fno-exceptions -fthrow-function=func"
                    is given... okay, I'm partially joking here, it'd
                    be easier to "#define throw(x)  abort()"
    throw-specs -> ignored

and also /heavily document this behavior/, then I believe this would be

    - way cool
    - well received by the people who feel that the simple presence of
      exception support imposes too much overhead on their code
    - very useful when such a user downloads a piece of GNUfree software
      that uses exceptions, but wishes to use such code in an exception-
      free environment

Could also be used to answer questions like, "How much impact would the
removal of exceptions have on the runtime / memory footprint of this code?"
although I doubt that question gets asked very often in industry.  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.