Re: CoreBase toll-free bridging

[Fred Kiefer]

On 10.03.2013 15:58, Luboš Doležel wrote:
> I've started working on toll-free bridging support for gnustep-corebase.
> I'm pushing my work to github:
>
> https://github.com/LubosD/gnustep-corebase

You are surely aware that the actual GNUstep development doesn't happen 
on github, we are still using our old fashioned SVN system.
And for your contribution to be usable by GNUstep we need you to signe a 
copyright assignment to the FSF. For small patches this will not be 
needed, but you seem to work on bigger changes.
I did not find your name on this list 
http://www.gnu.org/software/gnustep/developers/copyright.html, maybe the 
assignment is still being processed?

> So far I have NSString/CFString and NSArray/CFArray somewhat working and
> I'm moving to other types.
>
> The bridging is implemented via a helper category, so nothing in Base
> had to be touched for bridging to work in both directions. Given
> CoreBase's alpha state, it's the only feasible option anyway, I guess.

You change results in base not using its highly optimized internal 
NSString subclasses, instead it will use the CF implementation, which 
isn't and probably cannot be optimized that much. That way you don't 
just get toll free bridging, but all strings will be of the same type. 
You explained that in your later mail yourself. This should work, but is 
it the only way to do it? And the best one?

> There is one thing I cannot easily fix, though. @"Strings". On OS X,
> @"string" is a direct equivalent of CFSTR("string"). In other words, a
> constant CFString instance is created in the resulting binary.
>
> On Linux, though, we get this by default:
> http://gcc.gnu.org/onlinedocs/gcc/Constant-string-objects.html
> I don't see any reasonable/maintainable way of making this struct
> working with CFString; I believe the best way forward is to adapt
> Apple's approach and generate __CFString structs for every @"aaa".
>
> This is where ABI comes in, so David, what is your opinion? My suggestion:
>
> 1) Have clang generate __CFString's
> 2) Adapt NSConstantString to support this new struct layout
> 3) Make the CFTypeID of CFString constant forever (this is what they had
> to do in Apple CF/CFLite), as it will be part of the ABI
>
> As an aside, it should be discussed whether CoreBase's __CFString should
> contain a "hashCode" field. The one from Apple does not. I would make it
> go away for two reasons:
>
> 1) It gives me a headache in Darling, because this extra field doesn't
> fit into the original struct when doing fixups :-)
> 2) It makes the hash computation part of the ABI

Doing away with the hash code may result in a performance issue. I have 
done a few performance analysis for GNUstep gui applications and it is 
surprising to see what big portion of the runtime gets spend on 
comparing strings. This is one of the reasons Richard spend so much time 
optimizing the base string classes and why we even convert some of the 
constant strings into NSString to have a stored hash code. Maybe we 
could come up with a solution where the compiler provides the memory for 
the hash code and the actual GNUstep code fills that space up when the 
hash code is requested for the first time?