[basic-improvements] try/finally support for c/c++ - more tests

[Michael Matz]

Hi,

On Thu, 7 Nov 2002, Mark Mitchell wrote:

> > It's not like we're even breaking new ground on the language front.
> > Microsoft has supported try/finally in their C compiler for years.
>
> It has somewhat fancy semantics.  For example, you can catch
> floating-point exceptions this way

We don't.

> and other things that would be
> signals in UNIX.  They have a "__leave" keyword;

We don't.

> they have exception handling (as well as cleanups)

dito.

> and they have ways to say whether you keep unwinding, or stop where
> you are, when you hit the handler.

the same.

> It's partly because of Microsoft's stuff that I'm so nervous about
> this feature.

Then you are nervous not about the current proposal, but about a
theoretical possibilitywhat you think might also be implemented with it.

> We ought to be talking about new language features before we implement
> them, so we can have the arguments up front.

That would have been good indeed.  But I too do not understand at all the
resistance about this special extension, in the limited way in which it is
implemented.  It's not hard to think about it, it's not complicated, and
it's not difficult to see, that it _does_ fit well into C (and C++) and
doesn't make problems.  So from me it's a "hey that is cool" ;-)

> I apologize to Aldy too -- the patches are technically sound, and the
> goal of improving interactions between threads and C++ is a good one.

You still seem to concentrate on just the threading issue in glibc.
While that may have been the original reason to implement it, as already
demonstrated repeatedly it has other uses.  In fact I don't care a little
bit about threading, I'm not interested in how cancellation is
implemented.  In fact I think, once it is implemented in whichever way,
most users of GCC will not care about that.  But they will care about
expressive power of the language they use, and if they choose to use GNU
C, and we can provide them with an easy and esthetically appealing way of
doing cleanups, I can't find arguments against that.  In that respect it
even doesn't really matter (to me) if those cleanups are now run when
unwinding or not.  I find the possibility to reformulate goto gems (or
cascading cleanup-before-return blocks) already appealing enough.  If they
additionally also cleanup while unwinding, well, then all the better, but
it's not the main feature to me.

Using builtins, with function-call like syntax, but with funny semantics
resembling the cursed setjmp/longjmp approach is _not_ pretty.  This also
means, that all the other hacks^Wsolutions for the threading problem to
not have to integrate try/finally don't apply at all.  They all wouldn't
satisfy the above need.

The suggestion that I should use C++ isn't usefull, because right now that
language also hasn't cleanups in this way, therefore I would be forced to
implement them also with a hack, like a block local struct with a
destructor.  It's a hack because I don't want a destructor, I want a
cleanup.

> I promise not to be a complete jerk. :-)
>
> If everyone else wants to do this, I'll go along.

Of course I would also be fine with a different thing which implements
cleanups.  But as I pointed out in my first mail, from the need for
cleanups it's a failry direct way to the try/finally syntax, and currently
I can't think of a better way.


Ciao,
Michael.