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

[kaih@khms.westfalen.de (Kai Henningsen)]

jakub@redhat.com (Jakub Jelinek)  wrote on 08.11.02 in <20021108084659.A10988@devserv.devel.redhat.com>:

> On Fri, Nov 08, 2002 at 12:48:49PM +0000, Nicola Pero wrote:
> > Well you're not a lone voice of insance conservatism, I actually think you
> > are quite well giving voices to the puzzled C users, like me. :-)
> >
> > In all this discussion, I didn't quite find discussed how it would work in
> > C/ObjC, from a pure C/ObjC perspective.  Which IMO is essential to have
> > the C extension approved.
> >
> > The suggestion that this change is good because "it makes C look more like
> > C++ so that it's easier to integrate C and C++" might be good for C++
> > hackers and lovers, but it's definitely unconvincing for C/ObjC users with
> > no interest in C++.
>
> If you look at a typical system nowadays, C and C++ has to easily integrate
> together, as C++ code often calls C routines (starting from libstdc++ using
> C library functions where C library is most often written in C) and a lot of
> C programs/libraries are using C++ libraries too.

But, just like Nicola, I don't care about that part because I don't use  
C++ myself. Let this be solved by C++, not by C!

I *really* want *real* exception handling for C - doing this with setjmp/ 
longjmp (a.k.a. NS_DURING and friends) is just too ugly for words.  
Besides, it is dog slow - but this isn't it.

> then you IMHO have all you need for satisfactory pure C exception handling
> with minimal overhead.

Minimal overhead? Your definition of minimal is certainly not mine. Setjmp/ 
longjmp based exceptions in C are *SLOW* even for code which doesn't raise  
exceptions.

Besides, I'm sick and tired of "... may be clobbered by longjmp" because  
gcc cannot know how those jmp_buf's will be used.

> a) typically in such functions they are not returning void, but some value,
>    with __try/__finally you can leave the code as above, just add the
>    return value to each return statement. With goto gem you need some
>    function scope variable and set it first, then return,
>    so if (stringC == NULL) return 134; becomes
>    if (stringC == NULL) { ret = 134; goto finally; }
>    which is less readable

Look up NS_DURING and friends. It's not that it can't be hidden away in  
macrosm, because it can. It's that macros which expand with unbalanced  
braces are *extremely* easy to get wrong.

And, of course, setjmp is no speed demon, and putting chaining on top of  
that doesn't help.

MfG Kai