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?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev