Re: Implementing CFSTR() in corebase

[David Chisnall]

On 23 Jan 2010, at 02:45, David Chisnall wrote:

> On 23 Jan 2010, at 00:43, Stef Bidi wrote:
> 
>> - We need constant Obj-C/CF strings - it sounds like it is best to just use 
>> @"...".
>> 
>> It sure looks that!
> 
> I've just added __builtin___NSStringMakeConstantString() to clang, which 
> emits a constant Objective-C string from the (constant C string) argument.  
> 
> I've added CFSTR() macros to CFString.h that use this when it's available, 
> uses @ when compiling in Objective-C mode, and fails when compiling with GCC 
> in C mode (that version is left as an exercise to the reader).  

Now that I'm a bit more away:

For this to work with GCC you want to add '-x objective-c' to CFLAGS.  This 
will compile C code as Objective-C.  As long as you don't include any 
Objective-C headers, types like SEL, id, and Class won't be defined, so any 
valid C program will still compile.

For this to work with clang, you probably need to specify -fgnu-runtime 
(GNUstep Make does this already, because it does a terrible job of knowing the 
difference between C, C++, Objective-C, compiler and linker flags, so for once 
a bug in GNUstep Make is actually useful).

I've also added a fall-back now that creates and uniques CF strings at run 
time.  Note that the CFSTR() macro is not universally safe to use for static 
initialisers.  This is true even with Apple's implementation.  They added 
compiler support for constant CF strings some time after the first 
CoreFoundation release, so on some versions of OS X, and on Windows (where, for 
some reason, they don't use their own compiler?), CFSTR() will not return a 
constant object.  I've marked this function as pure, so that GCC will do some 
things like move calls to it outside of loops.  In theory, anyway.  It seems 
that GCC doesn't do loop invariant migration at all competently.  Yet another 
reason to use a better compiler...

David