------- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20 ------- Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | ------- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ------- | (In reply to comment #13) | > Subject: Re: exception_defines.h #defines try/catch | > | > I'm saying that if you're intending to use try/catch and yet not | > want what the mean in standard C++, nor what they would mean in GNU | > C++ with -fno-exceptions, then you have to watch what you're doing. | > Meaning, in your *own* codes, you #undef try/catch. Whether it is in | > Cocoa.h or foobar.c, I don't care. Just take your responsability to | > #undef them -- because you have decided to have mean something else. | > I'm not inclined in seeing the libstdc++ be uglified in that direction. | | I see, thanks for the clarification. | | It is my understanding that gcc 4.1 supports a language called Obj C++. I don't think anybody is disputing that. It is also a simple fact that GCC documents what happens with -fno-exceptions. In | this language (and I am by no means an Obj C++ expert) you can pretty much mix | & match Obj C and C++. I have customers using Obj C++ who want to turn off C++ | exception support, but retain Obj C exception support. They can easily do so | -- unless they include a libstdc++ header. The libstdc++ headers are messing | up their ObjC @try/@catch statements. That is, libstdc++ is not supportive of | ObjC++ in this manner. No. ObjC++ is messing with itself. -fno-exceptions is documented. Either you don't want to use it, and you don't. Or you want to use it and you have to abide by what it does. | They are not trying to use C++ try/catch in a bizarre or unsupported manner. Then, why what is this PR is about in the first place? -fno-exceptions turns try/catch into macros with specified semantics. If you don't like those semantics, either you don't use -fno-exceptions, or redifine the macros to meet your needs. [...] | That is a customer-hostile solution. Trying not to abide by the rules and getting back and shouting for hostility is a joke. A sad one, Howard :-( Asking for more uglification in libstdc++ just to fix ObjC++ is a hostile solutions, if "hostile" is found to be appropriate qualification in this discussion. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
