Re: Can one extend CoreFoundation using Obj-C?
Re: Can one extend CoreFoundation using Obj-C?
- Subject: Re: Can one extend CoreFoundation using Obj-C?
- From: Brian Cave <email@hidden>
- Date: Sun, 29 Jul 2001 20:05:41 -0500
On Sunday, July 29, 2001, at 04:10 PM, Brian Hill wrote:
On Sunday, July 29, 2001, at 01:20 PM, Brian Cave wrote:
I want to have a unique CFTypeID that my class exports that would be
unique in the same manner as these already are in the CoreFoundation
world, no better. And I want my class to be retainable / releaseable
using the CoreFoundation retain / release APIs. I do not desire any
more compatability than this.
I looked into this a while back, and even downloaded the portion of the
CF source in Darwin so I could see how it's done. Right now, it can't,
per se.
There are several limitations to the CF itself (a fairly restrictive
limit on the global number of CF types allowed in a single process --
255 -- for example), and the internal API that you'd need to use (which
you could dig out of Darwin) is very likely to change. In fact, I'd
almost put money on it having changed in 10.1.
However, someone on this list (I forget who, sorry) had the excellent
suggestion of wrapping my class around a CFData. Create some accessors
to store the class' private instance data (ie., a struct) in the CFData.
What I ended up doing in the end was to just create a separate set of
CF functions for my own class' use that paralleled the standard CF ones
(ie., CFXRetain instead of CFRetain). I also created my own set of
collection-handling functions for CFDictionaries and CFArrays that did
the right thing with both my own CF-like types and standard CF types.
Brian
I also have looked into the CF source from Darwin and saw the same
limitations you have described. But since this email I have dug more
deeply into the CF source code and I have come to the conclusion that it
should be possible to "extend" CF using Obj-C. Here is what I found:
1. Obj-C appears to build on top of a single CF type registered during
init of Foundation framework. The CF vs Foundation headers may or may
not be the exact same.
2. For CF APIs that might get an NSData, NSString, or other NS data
type, there is a macro that checks what kind of reference it has (i.e.
CF or NS). It will then call through to the NS implementation for the
same API if the CFTypeRef is of NS origins instead of CF (i.e. a
NSString* is passed instead of a CFStringRef). I have specifically
checked several CFString calls, CFRetain(), CFRelease(),
CFGetTypeID(), CFGetRetainCount(), CFEqual(), CFHash(),
CFCopyDescription(), CFGetAllocator(), and others.
3. There is a bridge init function which appears to init those classes
that have CF implementations. But this appears to work in the opposite
manner than first thought. It appears that those NS classes that have
CF implementations use the CF implementation when they haven't been
extended. That is, when base implementation of NSString is needed, it
uses CF. But the design still allows for NS sub-classing to override a
member function and get the expected behavior, even across the "toll
free bridge". This provides a seamless merging of the technologies.
Quite a smart arrangement. :-)
4. It appears that the default NSZone (for memory) is equivelent to the
CF default allocator. But NSZone is built differently (and is probably
private), so I will only be able to use the "default allocator" for
CF. But this is acceptable for me. If anyone finds that I have
overlooked something on this, let me know since I would prefer to keep
all aspects of CF in my APIs.
Or have I overlooked something big here? Anyway, there is only one way
to be sure and I will find out tomorrow when I build a simple test case
framework.
Thanks,
brian
_____________________________________________________
Brian Cave <
mailto:email@hidden>