[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CoreBase toll-free bridging
From: |
Maxthon Chan |
Subject: |
Re: CoreBase toll-free bridging |
Date: |
Wed, 27 Mar 2013 08:57:33 +0800 |
However this is the Apple approach. Can we just think out of the box and
maintain just API interoperability?
As I said, Apple used Core Foundation to serve both Cocoa and Carbon
simultaneously, which is asking for a C API (Cocoa was in Objective-C and
Carbon was C++, and there wasn't a good implementation of Objective-C++ then to
allow implementing Carbon or Cocoa on top of each other, thus a C API is called
for and Core Foundation is born. Before Cocoa, in NeXTSTEP ages, the NeXTSTEP
libraries sits directly on libobjc and libc, just like current GNUstep.) So
once again, it is okay for us to directly implement the entire CoreBase on top
of Base? Not to say that this will make CoreBase code more portable as it no
longer rely on the internal structure of the Objective-C runtime (To the extent
that one can even port CoreBase back to OS X if any CoreBase extras is called
for on an OS X app).
And just another idea, given that clang is now powerful enough, it is actually
possible for us to implement Carbon in Objective-C++ based directly on
Foundation (or Base).
在 2013-3-27,上午4:01,Luboš Doležel <address@hidden> 写道:
> Hi again,
>
> I was investigating what approach Apple took in solving a problem with
> calling CF functions on ObjC objects, which return an autoreleased object in
> ObjC, but clearly shouldn't do so when using the CF call.
>
> For instance, you have to release the result of CFTimeZoneCopyLocalizedName()
> yourself, but you mustn't do that with [NSTimeZone localizedName:locale:],
> since that will be autoreleased.
>
> An ordinary CF_OBJC_FUNCDISPATCH from the former to the latter therefore
> doesn't work correctly "out of box". Apple's source code showed no solution
> at all, but still on OS X it seemed to work correctly...
>
> So I took my disassembler again and voilá! The source code released by Apple
> under the 10.8 section *doesn't match* the OS X 10.8 binares. In CFTimeZone's
> case it doesn't match it at all.
>
> CFTimeZone on OS X is *entirely* built on top of NSTimeZone.
>
> CFTimeZoneCopyLocalizedName() actually does something like this:
>
> =====
> _CFAutoreleasePoolPush();
> NSString* retval = [(NSTimeZone*)tzSelf localizedName: arg1
> locale: arg2];
>
> CFRetain(retval);
> _CFAutoreleasePoolPop();
>
> return retval;
> =====
>
> Which explains why it doesn't exhibit the above described problem as one
> would expect from their source code.
>
> So Chan, you were partially right. But I've checked other types and it seems
> it is the case only in CFTimeZone.
>
> --
> Luboš Doležel
>
- Re: CoreBase toll-free bridging, (continued)
- Re: CoreBase toll-free bridging, Maxthon Chan, 2013/03/15
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/15
- Re: CoreBase toll-free bridging, Maxthon Chan, 2013/03/15
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/15
- Re: CoreBase toll-free bridging, Chan Maxthon, 2013/03/15
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/17
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/26
- Re: CoreBase toll-free bridging,
Maxthon Chan <=
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/27
- Re: CoreBase toll-free bridging, David Chisnall, 2013/03/27
- Re: CoreBase toll-free bridging, Ibadinov Marat, 2013/03/27
- Re: CoreBase toll-free bridging, Maxthon Chan, 2013/03/26
- Re: CoreBase toll-free bridging, Luboš Doležel, 2013/03/27