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

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

------- Comment #17 from gdr at integrable-solutions dot net  2005-12-04 02:54 -------
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| But I won't apologize for being customer focused.

Geeat!  And people disagreeing with you on this point are not necessary
customer unfocused.

[...]

| > No. ObjC++ is messing with itself.
| 
| I don't know what that means.  Or even how it would be relevant.  ObjC++ is
| what it is.  If you or I don't like ObjC++, is that relevant?

I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
If you believe that is the appropriate reduction, this is my last
message on the issue.  The rest clarifies what I said earlier.

This issue has nothing to do with liking or disliking ObjC++, not
matter how much of "hostility" or other "emotion" you would like to
inject into it.  ObjC++ got it wrong, it got it wrong.  The place to
fix it is in ObjC++.  That has nothing to do with liking or disliking
ObjC++. 

[...]

| I'm honestly very confused by that response.

I would not guess that it is partly because you seem to approach the
issue only from ObjC++-centric point of view.  This is issue is not
just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
try/catch when -fno-exceptions have been there long before ObjC++ came
in.  It is not like we're suddenly changing them.  
The uglification you're proposing is also breaking interfaces:  All
user codes that worked with both -fexceptions and -fno-exceptions and
used try/catch now will break.  I don't think I'm prepared to accept
that breakage.  The fix is simple for ObjC++: #undef them if it thinks
it wants both -fno-exceptions, libstdc++ headers.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191