c++ exceptions

[allstars]

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?
2. why 'The exception-enabled code generated for ARM by gcc was
unacceptable' ??
what kind of constrains on arm makes it harder to generate
efficient code ?

thanks

[Kaz Kylheku]

On 2009-11-10, allstars <allsta...@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?

[Kaz Kylheku]

On 2009-11-10, allstars <allsta...@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 my previous posting I also wanted to mention that unwinding support
in C can bring in some additional costs. The exceutable may have to have
an additional section which contains records that help the unwinder do its
job. So that is an increase in the executable size. On a VM system, you
may be able to avoid loading that into memory until it is needed; however,
it may be the case that these records contain address references that
need to be subject to relocation (e.g. for shared libraries which don't
have a fixed address). In that case, not only are they loaded, but due to the
modification, the pages have to be a process-private mapping (consumes
non-shared memory).