------- 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" <[EMAIL PROTECTED]> 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