gnustep-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]