Hi,
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
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.
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
Bye,
--
Luboš Doležel
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev