------- 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++. 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.
They are not trying to use C++ try/catch in a bizarre or unsupported manner.
They are simply trying to use ObjC++ exceptions without the unwanted cost of
C++ exceptions.
This is quite analogous to the C headers compiled under C++. <math.h>, under
C++, is supposed to behave a little differently than <math.h> under C. As a
C++ programmer I appreciate that some C vendors will make some modest
accomadations for me.
This seems to me like a very modest accomadation we can make for the ObjC++
programmer. Afterall, ObjC++ is a supported language of gcc now, and libstdc++
is part of that support. Asking every ObjC++ programmer to order the C++ and
ObjC headers and #undef things just right seems quite error prone to me when we
can easily solve the problem once and for all.
// C++ includes
#include <list>
#include <vector>
// Obj C includes
#undef try
#undef catch
#import <Cocoa/Cocoa.h>
#import "my_header.h"
#include <iostream> // oops, put C++ header in wrong place!
int main()
{
// ....
}
That is a customer-hostile solution.
-Howard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
