[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CoreBase toll-free bridging
From: |
David Chisnall |
Subject: |
Re: CoreBase toll-free bridging |
Date: |
Mon, 11 Mar 2013 08:13:45 +0000 |
Hi,
On 10 Mar 2013, at 14:58, Luboš Doležel <address@hidden> wrote:
> 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
I'd certainly be interested in improving the NSString structure. I put out a
request for this a while ago, but got no feedback.
There are a few problems, the most significant is that GNUstep periodically
does isa comparisons to determine if something is a constant string. Check the
code for comparisons against NXConstantStringClass. These would need fixing,
and we'd also have a transition period where we had two constant string classes.
Note that, to support CF code in GNUstep, clang exposes a builtin function in C
code for creating constant string objects.
> 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
Adding a hash field to NSConstantString is something I would definitely
support. For efficiency, there is a load of stuff in GNUstep that replaces
NSConstantString instances with GSString instances at load time because caching
the hash significantly improves performance when the hashes are stored in
collections.
We don't have to make the hash computation part of the ABI, we can simply
reserve a flag to indicate 'hash calculated.' The hash method would then check
this flag and return the hash field if it is set, or compute it if it isn't.
David
> Bye,
> --
> Luboš Doležel
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
-- Sent from my STANTEC-ZEBRA
- Re: CoreBase toll-free bridging, (continued)
Re: CoreBase toll-free bridging, Chan Maxthon, 2013/03/10
Re: CoreBase toll-free bridging,
David Chisnall <=
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/11
- Re: CoreBase toll-free bridging, David Chisnall, 2013/03/11
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/11
- Re: CoreBase toll-free bridging, Stefan Bidi, 2013/03/11
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/11
- Re: CoreBase toll-free bridging, Riccardo Mottola, 2013/03/11
- Re: CoreBase toll-free bridging, Stefan Bidi, 2013/03/11
- Re: CoreBase toll-free bridging, David Chisnall, 2013/03/11
- Re: CoreBase toll-free bridging, Chan Maxthon, 2013/03/11
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/11