Re: CoreBase toll-free bridging

[Chan Maxthon]

How about reversing the relationship on GNUstep: implement CoreBase in 
Objective-C. Everything except CFRetain() and CFRelease() can be built with 
ARC, and CF objects are typedef'd to their respective Objective-C counterpart. 
Apple invented CF to serve Carbon and Cocoa simultaneously, but we don't have 
that Carbon trouble so we can really bravely implement CF using Obj-C.

发自我的 iPad

在 2013-3-11，4:55，Fred Kiefer <address@hidden> 写道：

> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev