[Bug libstdc++/25191] exception_defines.h #defines try/catch
gdr at integrable-solutions dot net
gcc-bugzilla@gcc.gnu.org
Sun Dec 4 02:54:00 GMT 2005
------- 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
More information about the Gcc-bugs
mailing list