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

["hhinnant at apple dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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