That doesn't matter if we keep internal consistency. That is, the memory management of CoreFoundation objects are all done via bridging to Objective-C code, no matter if it is toll-free or not (For non-toll-free objects, the private Objective-C class corresponding to the CoreFoundation object is not complete, and does not have a public interface.)
If we can do the toll-free bridging in this fashion, our code can be a lot more compatible to Apple code. However, this may require promoting CoreBase from dev-libs into core, merging ti with Base. (that is, building Base will result in two libraries, libCoreBase and libgnustep-base, libCoreBase linked to libobjc2, and libgnustep-base linked to libCoreBase.) And about the missing CoreFoundation features that are already implemented in Base, how about moving code after this promotion? 在 2013-5-18，上午5:55，David Chisnall <[email protected]> 写道： > On 17 May 2013, at 17:48, Chan Maxthon <[email protected]> wrote: > >> All CoreFoundation objects places the field for retain count at the same >> offset as Cocoa objects do > > Cocoa objects do not have an in-object retain count. This is why retain / > release on GNUstep are so much faster than on OS X / iOS. On iOS, they are > all stored in a C++ map table (in fact, the LLVM one). In OS X, there is an > initial hash that selects one of 8 map tables, for greater parallelism in the > retain / release operations. > > David > > -- Send from my Jacquard Loom > _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
