Re: Toll-free bridging, say for NSDictionary and CFDictionary.
Re: Toll-free bridging, say for NSDictionary and CFDictionary.
- Subject: Re: Toll-free bridging, say for NSDictionary and CFDictionary.
- From: "email@hidden" <email@hidden>
- Date: Fri, 21 Aug 2009 17:09:53 +0100
On 21 Aug 2009, at 16:32, Alastair Houghton wrote:
On 21 Aug 2009, at 15:56, email@hidden wrote:
We can dig into http://www.opensource.apple.com/source/CF/CF-476.19/CFDictionary.c
and sure enough we find buckets being probed.
But what does this tell us about NSDictionary?
Yes, we know it's toll-free bridged to CFDictionary but does that
imply total equivalence at both the data structure and method/
algorithm level?
Does NSDictionary merely defer to CFDictionary for all its
functionality or or they functionally distinct, ie: is NSDictionary
implemented via calls to CFDictionary?
Is the answer to the above question true for all toll-free bridged
Cocoa classes?
You can see the toll-free bridging mechanism (at least the Core
Foundation side of it) in the CF sources (take a look in particular
at CFInternal.h in Base.subproj, where you'll see the CF_IS_OBJC()
function).
Looking at the source history it would seem that this used to be the
case.
eg: http://www.opensource.apple.com/source/CF/CF-299.33/Base.subproj/CFInternal.h
CF_INLINE int CF_IS_OBJC(CFTypeID typeID, const void *obj) {
return (((CFRuntimeBase *)obj)->_isa != __CFISAForTypeID(typeID)
&& ((CFRuntimeBase *)obj)->_isa > (void *)0xFFF);
}
The current source at http://www.opensource.apple.com/source/CF/CF-476.19/CFInternal.h
has the following definition
#define CF_IS_OBJC(typeID, obj) (false)
Don't know if this is symptomatic of internal changes in CF or part of
the CF-lite open source policy.
Also, if you look at an object of type e.g. NSDictionary or
NSString, you'll see that its class is actually NSCFDictionary or
NSCFString (and so on), which is a big hint in and of itself.
You'll also note that the various Core Foundation type/class
structures are defined so as to be compatible with Objective-C;
CFRuntimeBase, for instance, which is the header of all Core
Foundation objects, starts with a void pointer named "isa", and you
can see that CF_IS_OBJC() in CFInternal.h checks the isa pointer to
see whether it matches the isa pointer for the bridged ObjC class
and returns false in that case. CF_IS_OBJC() is then used in the
various CF_OBJC_FUNCDISPATCH macros to check whether or not Core
Foundation should call back into Objective-C.
The way NSCFDictionary et al. are implemented is that the isa
pointers for CFDictionary objects are set to point to the
NSCFDictionary class. There will be method implementations for
NSCFDictionary, but for the most part they'll just call the Core
Foundation functions to do the work. Similarly with the other toll-
free bridged classes. There are one or two instances where there is
additional functionality implemented on the Cocoa side, and a fair
few where Core Foundation is more flexible, but to answer your
question it does generally seem to work that way, yes.
If you *really* wanted, you could disassemble the methods on e.g.
NSDictionary to see what they do. I think (because I've looked)
that you'll find that they often jump straight to their Core
Foundation counterparts.
Thanks Alastair, this is a great answer. Plenty of exploring ahead!
thanks
Jonathan
Kind regards,
Alastair.
--
http://alastairs-place.net
Jonathan Mitchell
Developer
http://www.mugginsoft.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden