Nat!'s Web Journal

>On Apr 26, 2005, at 3:13 PM, Mike Stump wrote:
>I'm pushing the Objective-C++ frontend into the FSF source tree on mainline. 
>In doing this, I'm also pushing various 
>updates to the Objective-C language; fast dispatching,
>GC, a new warning or two, a way to get at C++ ctors/dtors from a 
>ObjC method.  Most of these would require library work to be complete.

Some details:

* fast dispatching
The compiler assumes that a copy of objc_msgSend() is at a fixed memory address, and jumps directly to it. This is most useful in the context of PowerPC and Mac OS X's dynamic linker: the dynamic linker overhead for cross-library calls is significant, and the fast objc_msgSend() can be placed in a memory range that is reachable by single absolute branch instruction. I don't know how interesting this change is for GNUstep, given GNUstep's portability goals.

* GC
Apple is working on a garbage collection system for Objective-C. It is still under development, but does not use the Boehm GC available in GNUstep. These compiler changes mostly add a write barrier when assigning Objective-C instance pointers to ivars and a few other places. The write barrier is a runtime function, and is similar to the fast dispatching above. This is likely to evolve further, and probably isn't interesting for GNUstep yet.

* C++ ctors / dtors
In Objective-C++, an Objective-C class may have ivars that are C++ objects with constructors and destructors. This compiler change emits -.cxx_construct and -.cxx_destruct methods containing the C++ default constructors and destructors for these classes. The runtime calls these methods during instance allocation and deallocation.

The ctors/dtors are probably interesting for GNUstep, because it makes Objective-C++ much easier for the programmer. Apple's runtime support is new in Tiger, so you'll be able to see it in the upcoming Darwin release. Adding support to GNU libobjc should be straightforward.

--
Greg Parker xxxxx@apple.com Runtime Wrangler