This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]