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

[Dirk Mueller]

< flhf30vu5v.fsf@sel.cmla.ens-cachan.fr >,
     < u94ryzc2qm.fsf@casey.cambridge.redhat.com > 

Hi, 

> Adding ugly macros to the library just because the compiler enforces 
> silly restrictions would unquestionably be a workaround.  

The compiler is just careful, there is nothing wrong with that. Imagine a 
bigger project that consits of many separated parts that still have to work 
together. Some parts of that need exceptions support, others don't. If a 
compiler would simply ignore the EH statements when -fno-exceptions is used 
this would be VERY DANGEROUS as soon as the code evolves. It can cause many 
unnecessary and hard to find bugs, especially as avoiding all this hassle is 
such an easy job in this case. The only possible solution for the compiler 
would be issuing a warning for every EH related statement it parses. I hope 
we can agree that this is completely inacceptable. The compiler simple can 
not know when and where the ignoring of exceptions is acceptable. 

> With "-fno-exceptions", the current compiler rejects "throw()"
> decorations on function declarations.  Ugly macros would be needed 
> to work around that behavior.

Ugly macros? I don't think so. There's nothing difficult or broken with 
those macros. Please think about it, the libstdc++ is such a central lib for 
a C++ environment, people will use it in wany different ways, it is even 
designed very clearly to be easily customizeable and extensible. I don't 
need to remind you on that, I know. So please, accept that people might 
be forced to have a standard library that will fit their needs. Right now 
this does not seem to be the case. 

I tried to explain why the only possible solution is right now is when 
at least the header files of libstdc++ are compileable without 
exceptions support. As iostream.h includes the mentioned header file, right 
now each and every bit has to be compiled with exception support, which adds 
an _inacceptable_ huge overhead to the code. 

This does not have anything to do with a crippled environment or a broken
compiler. EH suport requires a certain overhead. Programs that don't need
this overhead should not be forced to use it. We're not talking about a
specialized library for certain needs, we're talking about the most standard 
and most basic library that is necessary for programming in C++!


Dirk