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.
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?
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?