------- Comment #16 from hhinnant at apple dot com 2005-12-04 02:12 ------- (In reply to comment #15) > Subject: Re: exception_defines.h #defines try/catch > > I don't think anybody is disputing that. It is also a simple fact > that GCC documents what happens with -fno-exceptions.
I think it is good that gcc documents what it does, and I am also impressed with the gcc documentation in general. But just because something is documented doesn't make it the best answer. Thank you for letting me know this behaivor is documented (I hadn't even tried to look that up, and still haven't found it). It is still a customer-hostile solution. > Trying not to abide by the rules and getting back and shouting for > hostility is a joke. A sad one, Howard :-( I'm not shouting (no caps, not even an exlamation point), but perhaps my vocabulary needs explaining. I'm a pretty simple guy. And I'm also very customer focused in everything I do (even in situations that are not traditionally vendor/customer). If a solution seems to work for customers very well, I'll often call it customer-friendly. If a solution seems to work for customers very poorly, I'll often call it customer-hostile. I'm not trying to shout or make any jokes. It is simply the way I work. My apologies for not explaining that up front. But I won't apologize for being customer focused. That focus has served me well over the past two decades. If I provide a service, and those who I'm providing the service to don't find that service useful, I'll look inward first - every single time. I'll continue to think about solutions from the customer's viewpoint as best I am able. And if or when I ever find myself having trouble doing that, I pray I'm able to retire. > 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? > Either you don't want to use it, and you don't. Or you want to use it > and you have to abide by what it does. Maybe it does the wrong thing. We have customer complaints. > Then, why what is this PR is about in the first place? My bad for not explaining it better in the original post. This PR is about the fact that although our customers find the compiler's definition of -fno-exceptions useful, and want use it, but they find the libstdc++'s reaction to this compiler flag unhelpful. Furthermore, making libstdc++'s behavior under -fno-exceptions to actually be useful for our customers is nearly trivial. Yes readability takes a minor hit. But functionality/usefulness increases. I really don't even understand why this is controversial. This is a minor issue that will have absolutely no impact on our C++ customers, and will make our ObjC++ customers much happier. If someone had raised a point about how we are harming our C++ customers with this fix, I would have been alarmed and searched for a solution that didn't harm our C++ customers. If it was a major imposition from an implementation point of view, I would be alarmed. But as it is, all I'm hearing is that there is an objection to helping our ObjC++ customers at the expense of a very minor readability hit in libstdc++ internals. I'm honestly very confused by that response. -Howard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
