[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CoreBase toll-free bridging
From: |
Chan Maxthon |
Subject: |
Re: CoreBase toll-free bridging |
Date: |
Mon, 11 Mar 2013 06:04:42 +0800 |
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
Re: CoreBase toll-free bridging,
Chan Maxthon <=
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, 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