Re: c++ exceptions

Kaz Kylheku <kkylheku@gmail.com>
Fri, 13 Nov 2009 21:16:04 +0000 (UTC)

          From comp.compilers

Related articles
c++ exceptions allstars.chh@gmail.com (allstars) (2009-11-09)
Re: c++ exceptions kkylheku@gmail.com (Kaz Kylheku) (2009-11-13)
Re: c++ exceptions kkylheku@gmail.com (Kaz Kylheku) (2009-11-13)
| List of all articles for this month |

From: Kaz Kylheku <kkylheku@gmail.com>
Newsgroups: comp.compilers
Date: Fri, 13 Nov 2009 21:16:04 +0000 (UTC)
Organization: A noiseless patient Spider
References: 09-11-032
Keywords: C++, errors, performance
Posted-Date: 15 Nov 2009 17:45:55 EST

On 2009-11-10, allstars <allstars.chh@gmail.com> wrote:
> hello
> i've seen a post in other group (android-ndk)
>
> http://groups.google.com/group/android-ndk/browse_thread/thread/89db67ed1fbf6450?hl=en
>
>
> and i have a couple questions
>
> 1. How would c++ exception support slow down C applications?


In a number of ways.


The function call ABI for C may have to be altered somehow in order to
support unwinding through the call frames of C functions. This ise
because even though though the C functions don't use exception
handling, the C++ code may have to traverse a call stack with C
functions in order to find a handler.


Of course, this could be a code generation option for the C.


Being able to traverse the call stack is beneficial to C anyway,
because it's needed for supporting things like coverage and profiling
tools, and in general, technologies that require call frame
introspection.


The ABI of the C compiler might choose to implement setjmp and longjmp
in a way which plays nicely with C++ exceptions, and unwinding. So C
programs using setjmp and longjmp will may have their performance
affected by this by the relationship between the C compiler and the
C++ compiler. Traditionally, setjmp implementations simply dump a
bunch of registers into a little block of memory. The longjmp is very
fast; it just restores the context. A setjmp/longjmp that work
together with C++ will likely have a faster setjmp, since setjmp won't
have to dump as much machine state into a buffer. But the longjmp may
be slower since instead of just reloading some machine registers, it
will unwind the call stack all the way up to where the setjmp is, call
C++ destructors along the way and so on. (Perhaps the longjmp may even
be interceptable as a C++ exception using catch(...) { } and re-thrown
u using throw; ).




> 2. why 'The exception-enabled code generated for ARM by gcc was
> unacceptable' ??


I won't answer this because I'd have to read that whole thread to discover
who has the opinion that something is unacceptable and for what reasons.


How about, just dig out the e-mail addesses and ask those people to
clarify?



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.