Core Foundation meets C++

I am tired of dealing with Core Foundation ornerinesses in a program primarily written in C++, so I decided to write a library of RAII wrappers for Core Foundation classes I use commonly.

My first problem was that I didn't really understand about overloading assignment operators, but I think I've figured them out now.

The next concern is that for many types, there are mutable and immutable version, which differ only by a const in their typedef to the opaque underlying type. My first thought was to implement, for example, CFMutableArrayRef and CFArrayRef wrappers separately.

My next thought was to set up some kind of inheritance.
Inheritance fails, however. If we want to say that the wrapper for the immutable inherits from the mutable, and makes some member functions/operators private, then we'll run into the problem that an instance of a derived class must be able to function as an object of the base class, and a derived class wrapping an immutable object cannot act the same as a base object that is mutable.

Third try: Make the private data member mutable, but provide a const "conversion operator" that will make it act like it's immutable. This seems like the best option so far.

I am planning to make the library available once it's usable. I am still deciding on the licensing system I wish to use, but I think I am leaning toward BSD-style, or maybe Creative Commons.

C string to CFString

I have a null-terminated string of (random) ASCII chars that I need to convert to a CFString for an API call. However, the following call yields NULL:

CFStringRef convertedValue = CFStringCreateWithCString(kCFAllocatorDefault, c_string, kCFStringEncodingUTF8);

According to the doc, this means "there was a problem creating the object."
I am currently stumped as to why.

CFFork

It is absolutely forbidden to use Core Foundation or higher-level APIs in a child process after fork()ing, before exec*()ing. This royally messes up our process model.

citation: OS X Leopard Core Foundation Release Notes

CoreFoundation and fork()
Due to the behavior of fork(), CoreFoundation cannot be used on the child-side of fork(). If you fork(), you must follow that with an exec*() call of some sort, and you should not use CoreFoundation APIs within the child, before the exec*(). The applies to all higher-level APIs which use CoreFoundation, and since you cannot know what those higher-level APIs are doing, and whether they are using CoreFoundation APIs, you should not use any higher-level APIs either. This includes use of the daemon() function.

Additionally, per POSIX, only async-cancel-safe functions are safe to use on the child side of fork(), so even use of lower-level libSystem/BSD/UNIX APIs should be kept to a minimum, and ideally to only async-cancel-safe functions.

This has always been true, and there have been notes made of this on various Cocoa developer mailling lists in the past. But CoreFoundation is taking some stronger measures now to "enforce" this limitation, so we thought it would be worthwhile to add a release note to call this out as well. A message is written to stderr when something uses API which is definitely known not to be safe in CoreFoundation after fork(). If file descriptor 2 has been closed, however, you will get no message or notice, which is too bad. We tried to make processes terminate in a very recognizable way, and did for a while and that was very handy, but backwards binary compatibility prevented us from doing so.

cfstring parsing

Why are strings so annoying?

I'm trying to take integer values from a c-string, but only if it's well-formed. Using CFNumberFormatterGetValueFromString works if I can correctly determine the boundaries of the number portions. The difficulty is determining where those are. The formatter still gives a value if the range contains, for example, 5e. The desired behavior is for it to return false is such a situation.

Can anyone recommend a better way to parse a CFString, so that I can determine if the string is well-formed, and get the values if so?

Edit: traversed the c-string, finding ranges and delimeters by hand.

core foundation file manager

It's fun to reduce one problem to an already-solved problem.
I was working to remove all uses of the NSFileManager and replace them with faster CF file manager calls. I have one last function to fix, and even that is done (sans debugging) except that it relies on being able to determine if a file exists at a path held in a CFStringRef. I have a function

bool MyClass::fileExistsAtPath(NSString *filePath)
{
  return [[NSFileManager defaultManager] fileExistsAtPath:filePath];
}

but I want it to be

bool MyClass::fileExistsAtPath(CFStringRef path)
{
  return ???;
}

I have been searching the documentation, and I thought I could use a CFURL for this, but so far, I don't see any API that will tell me whether the url is valid.