Why are some libraries in iOS provided with a C-based API?
Why do some libraries in iOS provide C based APIs? For example, the Core Graphics library is provided by a C based API. But I can't figure out why Apple did this.
Also [[UIColor red] setStroke]
, which is the kind of code in drawRect: also confuses me! If Apple decided to use a C based API, why are they using object oriented style code to do graphical things?
And CGContextAddLineToPoint()
, for example, it takes an argument CGContextRef c
. I think it is quite suitable for using object oriented things.
// current
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextMoveToPoint(context, 0, 0);
CGContextAddLineToPoint(context, 10, 10);
// looks better
CGContext *context = [UIGraphics getCurrentContext]
[context moveToPoint: CGMakePoint(0, 0)] // or [context moveToPointX: 0 y: 0]
[context addLineToPoint: CGMakePoint(10, 10)] // or [context addLineToPointX: 10 y: 10]
So why is Apple using C based APIs for some of the libraries?
source to share
One of the possible reasons is performance.
When you send a message to an object, the compiler translates it into a named C function call objc_msgSend()
that takes as parameters the object to which you send the message, the message, and any message parameters. It then tries to figure out where the actual function corresponding to that message is and passes control to it.
I'm sure Apple has optimized the hell out objc_msgSend
since it was so often called, but it will still be much slower than a simple function call.
source to share
One of the reasons for abstraction can be found in the history of Apple. When Cocoa made its Mac debut (like the Yellow Box in Rhapsody OS), many major developers were reluctant to port their user interfaces to it. As a result, the existing Mac Toolbox was cleaned up and released with Cocoa as "Carbon" when shipping Mac OS X 10.0.
Carbon and Cocoa had a lot of function overlaps, so there were a lot of generic C-based libraries. While Carbon became popular, iOS came along and C libraries continue to be used for abstraction between Apple operating systems - between AppKit and UIKit.
NB: Generally, you should try to use the highest level API that suits your needs. For example, if UIBezierPath
u are UIColor
given what you want, then you can (and probably should) stay in the Objective-C garden for readability, ease of debugging, and future protection. However, as functionality and performance requirements are demanding, you can always go back to CoreGraphics. Along the same lines, if you need to handle streaming concurrent tasks in your application, subclassing NSOperation
is a clean and consistent way to go, but if your needs are unique, you can always fallback to GCD methods dispatch_()
.
source to share
First, C
it is a lower level language with less overhead. When you introduce objects, you introduce a small overhead in exchange for a program structure that is easier to execute in most cases.
In addition, due to the fact that iOS and OS X are based on the Unix kernel, any low-level OS integration provided in the Apple API is either written in a more commonly used cross-platform language, for example, C
or written as a wrapper around the same functionality C
. At some point, it's not worth Apple the time to provide Objective-C
wrappers for everything.
source to share