The fast paths follow the pattern that we established for fast ARC:
Framework base classes can opt in by implementing a `+_TrivialAllocInit`
method.
This opt-in behaviour is inherited and is removed implicitly in any
subclass that implements alloc or init methods (alloc and init are
treated independently).
Compilers can emit calls to `objc_alloc(cls)` instead of `[cls alloc]`,
`objc_allocWithZone(cls)` instead of `[cls allocWithZone: NULL]`, and
`objc_alloc_init` instead of `[[cls alloc] init]`.
Direct methods don't require very much support in the runtime. Apple
reuses their fast path for `-self` (which is supported only in the Apple
fork of clang, not the upstream version) for a fast init. Given that
the first few fields of the runtime's class structure have been stable
for around 30 years, I'm happy moving the flags word (and the
initialised bit, in particular) into the public ABI. This lets us do a
fast-path check for whether a class is initialised in class methods and
call `objc_send_initialize` if it isn't. This function is now exposed
as part of the public ABI, it was there already and does the relevant
checks without invoking any of the message-sending machinery.
Fixes#165#169
Methods now include a selector and extended type encoding, rather than a
method name and lgacy type encoding. Older ones are auto-upgraded.
Expose the extended type encoding via a function that JavaScriptCore
expects to exist.
at the start of the structure, making it easier to change the layout in
the future.
Also clean up the growth of various fields and consolidate some of the
metadata into a pointer to the `struct objc_method`.
clang trunk if -fobjc-runtime-1.7 is specified and provides significantly
better interoperability with foreign exceptions.
Note: Most of the exception tests will not pass with gcc or clang < 3.3. They
test things that are impossible to implement quite correctly with the
GCC-compatible exception ABI.
Also updated the release notes to reflect recent improvements.
Weak references are still not supported, but code that doesn't use them (i.e. any code that wants to be compatible with OS X 10.6) will work fine.
The current implementation is VERY inefficient and has a large number of missed optimisation opportunities: this is the 'make it right' phase, and should be almost equivalent to explicit retain / release code.
catching Objective-C objects in C++ catch statements (i.e. they follow
Objective-C semantics, not C++ semantics, irrespective of whether you use C++
or ObjC syntax). We now default to Apple-compatible behaviour, but provide a
function that allows users to select the sane semantics if they prefer.
Added a capability bit for the unified exception model, so code can require it.
This is not really required, since any code using it will link against the
ObjC++ personality function and will get a linker failure if it isn't supported.
Also enabled Objective-C++ stuff by default. This adds a dependency on the C++
standard library (actually on libsupc++, but GNUstep Make wants to link against
libstd++ anyway), which is not ideal. It can be disabled with:
$ gmake objectiver-cxx=no
I suggest that this is only done by people who know that they will never want
Objective-C++ support.
sandyx86
David Chisnall
David Chisnall
Frederik Seiffert
David Chisnall
David Chisnall
theraven
thebeing
ericwa