[Bug libstdc++/25191] exception_defines.h #defines try/catch

["gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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" <gcc-bugzilla@gcc.gnu.org> 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