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

hhinnant at apple dot com gcc-bugzilla@gcc.gnu.org
Tue Dec 6 01:19:00 GMT 2005



------- Comment #19 from hhinnant at apple dot com  2005-12-06 01:19 -------
(In reply to comment #17)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> "hhinnant at apple dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | 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.

Message #16, starting with the paragaph:

> This PR is about the fact...

states what I think this issue reduces to.

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

I'm sorry if you find my vocabulary offensive, even after I've politely
explained myself.  "customer-friendly" and "customer-hostile" are terms I've
used for a long time.  I find them self explanatory, to the point, and not
inflamatory.  Would "customer-friendly" and "not customer-friendly" work better
for you?  I'm certainly willing to change my vocabulary.

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

How did ObjC++ get it wrong?  And what is "it"?

> I would not guess that it is partly because you seem to approach the
> issue only from ObjC++-centric point of view.

<chuckle>  I would not guess that either, considering my background.  Indeed
I'm trying my best not to approach this from a C++ 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.

Thank you for pointing me to our documentation.  We apparently do not document
the behavior you want to preserve.  Therefore we will not be breaking anything.
 If user code is using try/catch and -fno-exceptions at the same time, it is
doing so at its own peril.  Simply omitting a standard header from the
customer's code could change compiling code into non-compiling code.

#include <limits>  // breaks under -fno-excetions if this header is removed

void foo()
{
     try 
    {
         bar();
    }
    catch (...)
    {
    }
}

>  The fix is simple for ObjC++: #undef them if it thinks
> it wants both -fno-exceptions, libstdc++ headers.

If this fix were simple, then great.  But it isn't simple because each ObjC++
customer has to re-implement it, and not just in one place, but in every single
translation unit.  And it doesn't even work in general if ObjC++ headers can
contain @try/@catch and contain std::lib includes:

// C++ includes
#include <list>
#include <vector>

// Obj C includes
#undef try
#undef catch
#import "my_header.h"   // oops, my_header.h includes <iostream>!

That's a maintenance nightmare for the ObjC++ customer!  And the reason we put
the customer through this is so that we can read "try" instead of "__try" in
the libstdc++ implementation?

If we really wanted to fix this right, we'd get rid of 95% of the try/catch
clauses in the first place (via RAII techniques).  Then we wouldn't have to
read "try" or "__try" (except very rarely).

-Howard


-- 


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



More information about the Gcc-bugs mailing list