[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: __NSCF** classes and libobjc2 dependency on C++ runtime
From: |
David Chisnall |
Subject: |
Re: __NSCF** classes and libobjc2 dependency on C++ runtime |
Date: |
Tue, 4 Jun 2013 09:45:35 +0100 |
On 3 Jun 2013, at 23:45, Maxthon Chan <address@hidden> wrote:
> 1) Apple's libobjc depend on LLVM's libc++abi (in Linux, it should be
> libsupc++). Not only Apple did that to allow proper Objective-C++, but also
> something more.
> When an Objective-C exception is triggered and not caught in Objective-C
> code, it will be raised as a C++ exception. This happens no matter if your
> code have C++ or not. Here is an crash log explaining this: (MobileDeuterium
> is the app I wrote. It have zero C++ in it.)
Please try to actually pay attention to GNUstep at some point if you insist on
having opinions about it.
libobjc2 correctly handles interoperability with C++ exceptions and interacts
with libsupc++ or libcxxrt (if you'd bothered to even compile it, you'd have
seen the check where it looks for this library) and will correctly allow
Objective-C++ code to catch Objective-C objects in C++ catch blocks (and throw
Objective-C objects in throw statements that can be caught with @catch).
Version 1.7 and clang 3.3 introduces a new exception ABI that makes this
significantly cleaner. The test suite contains a number of tests for correct
exception propagation.
Oh, and you're wrong. The way Apple implements Objective-C exceptions is to
construct C++ type_info objects and just use the same personality function for
C++ and ObjC. It doesn't raise it as a C++ exception when 'not caught in
Objective-C code', it raises it as a C++ exception all of the time.
objc_exception_throw() in the Apple runtime is just a thin wrapper around
__cxa_throw().
And no, we don't want to copy their implementation because it has some ugly
corner cases (try catch (void*) sometime) that cause segfaults where the
GNUstep runtime does the right thing. Oh, and the Objective-C personality
function is simpler (and faster) than the C++ personality function, so only
going via C++ when we are actually using C++ saves us some overhead.
Finally, do you honestly think that, after implementing both libobjc2 and
libcxxrt (the C++ ABI / runtime library used in FreeBSD, NetBSD, and soon
OpenBSD), not to mention the unwinding code for non-local returns in
LanguageKit, that I didn't know how exceptions work?
The rest of your email is completely irrelevant to the exception handling issue
and is mostly wrong. How toll-free bridging works is well documented in a
number of places. If you want to understand it, try reading the docs sometime.
David
--
This email complies with ISO 3103