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 <fredkie...@gmx.de> 写道： > 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
