This is the mail archive of the
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Michael Matz <matz at suse dot de>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Matt Austern <austern at apple dot com>,Zack Weinberg <zack at codesourcery dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 Nov 2002 17:58:50 +0100 (CET)
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
On Tue, 12 Nov 2002, Mark Mitchell wrote:
> I (and probably Matt) are going to argue that the burden is not on us
> to provide a specific reason *not to* have an extension; the burden is
> on you *to* provide a specific reason to have the extension.
I feared that argument chain ;-) But I think I (and others) did provide
some arguments, one of them being elegance (and by that possibility to
write more constructs in a non so error-prone style).
> Anyhow, I think you're beating a dead horse. :-)
> Richard has agreed to try to implement and use longjmp_unwind. There's
> no question that function would be useful to people in other situations,
> and it doesn't require any language extension. If Richard's attempt
> fails for some reason, we can reconsider.
And this is what I feared too. That Richards offer to implement a very
narrow case with not nearly the usability and elegance of the original
proposal implicitely removed the extension from any consideration,
although there's precedent for it in other C dialects. I mean people who
think longjmp and friends are elegant can't be helped (sorry to whoever I
described with this ;-) ).
Unfortunately I also think that Richard will of course succeed :) , so I
think I know what will happen with the proposal. Then we will have the
compiler without that extension for the next decade or so and no standard
body will consider its inclusion into C, because the only widespread
compilers supporting it are for one platform, and those compilers also
implement questionable extensions to that extension (erhh, well you know
what I mean ;-) exceptions and such). I.e. all in all I think we miss a
chance, but well, so be it. There's nothing more to say for me on this
P.S.: Ok, a last attempt: I just saw, that even EDG does support
__try/__finally. Ok, only in Microsoft mode, but still ;-) If that
doesn't make GCC one of a very limited set of compilers _not_ accepting
it, I don't know ;-)