[Top][All Lists]

[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 

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. 


This email complies with ISO 3103

reply via email to

[Prev in Thread] Current Thread [Next in Thread]