Re: __NSCF** classes and libobjc2 dependency on C++ runtime

[Chan Maxthon]

Indeed I am not that sure about how GNUstep currently handles exceptions but I 
am giving you ideas from some crash reports with symbols from an Apple system.

And the conclusion on toll-free bridging is about the latest Apple 
implementation. You should really get a Mac and poke around. Just for your 
information, what I poked around with is OS X 10.8.3 and iOS 6.1.3, both.

With non-fragile ABI it is almost impossible to construct a C struct that can 
perfectly mirror Objective-C objects' memory layout, especially under some 
corner circumstances. Apple found that out, and moved lots of code from 
Foundation to CoreFoundation so that CoreFoundation types are now all defined 
in a fashion that is compatible with new ABI.

Try breakpoint on some vital Objective-C runtime functions and methods and run 
some CoreFoundation code, and you will be surprised. Before you do that, make 
sure you have latest OS X and Xcode.

发自我的 iPad

在 2013-6-4，16:45，David Chisnall <address@hidden> 写道：

> 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
>