[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CoreBase toll-free bridging
From: |
Luboš Doležel |
Subject: |
CoreBase toll-free bridging |
Date: |
Sun, 10 Mar 2013 15:58:56 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 |
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
- CoreBase toll-free bridging,
Luboš Doležel <=
Re: CoreBase toll-free bridging, Chan Maxthon, 2013/03/10