Since Objective-C is basically an extension of C, Does the code get converted to pure C code before it is compiled to native code ?
If so, does the conversion happens on RAM or a temporary file containing C code on disk is created by the compiler which is further compiled by C compiler to native code ?
That Objective-C syntax is an extension of C syntax does not mean that it could not have its own compiler. C++ is the same way - its syntax is compatible with C (for the most part, anyway) but it has its own set of tools. Compilers for C, C++, and Objective-C can reuse parts of each other for preprocessing, syntactic analysis and code generation, but there is not need to run them sequentially (e.g. Objective-C ==> C ==> Target code). Compilers no longer go through human-readable assembly language, either (this has been the case for a very long time, too).
No, Objective-C gets compiled to assembler directly (assuming GCC).
Related
I have heard that C doesn't have closure, and today I saw the use of closure in Objective-C. Is closure supported in Objective-C and not in C?
Update: thanks for all the answers. I found this guide on the web on blocks as well: http://pragmaticstudio.com/blog/2010/7/28/ios4-blocks-1
Apple added the ^ operator to add closure support. It is not tied to Objective-C however, and can be used in C and C++ as well, as long as you compile the project with Apple's brach of GCC or LLVM. This new feature is called blocks.
C has closures in the form of application-defined structures that contain both a function pointer and data pointer. The problem is just that many/most interfaces that take a callback pointer (like qsort) accept only the function pointer and not a corresponding data pointer, making it impossible to pass closures to them.
By the way, it's theoretically possible to add closure support at the library level without assistance from the compiler, i.e. create a library that would return a function pointer to a closure. However, the library code would be rather implementation/machine-dependent. It would need to allocate space for executable code and generate code to pass a fixed pointer value (saved as part of the closure object) along with other arguments to the function.
I know objective C is strict superset of C and we are writing the same thing.
But when i write
#interface Myintf {}
#end
Does it get converted to a C struct or is it that the memory layout for the data structure Myintf prepared by Objective c compiler is same as that of a C struct defined in runtime.h?
and same question about objc_msgsend
Apple document says
In Objective-C, messages aren’t bound to method implementations until runtime. The compiler converts a message expression, into a call on a messaging function, objc_msgSend. This function takes the receiver and the name of the method mentioned in the message—that is, the method selector—as its two principal parameters:
Does it get converted to a C struct
In the old days it used to, but with the modern runtime (OS X 10.5+ 64 bit and iOS), I think it's a bit more complicated. It can't be using a traditional struct because the Fragile Instance Variable problem is solved.
and same question about objc_msgsend
Yes. All method invocations - or more correctly, all message sends - are converted into calls to obj_msgsend() (except for when super is used as the receiver when a different C function is used).
Note that early implementations of Objective-C were implemented as a preprocessor and produced C source code as an intermediate step. The modern compiler does not bother with this and goes straight from Objective-C source code to an object code format.
No and no. Both cases ultimately rely on the runtime. In a way, it is converted to use C interfaces, but there is a level of abstraction introduced -- it's not entirely static.
It will help to look at the assembly generated by the compiler to see how this works in more detail.
Given the declaration:
id objc_msgSend(id theReceiver, SEL theSelector, ...);
The compiler inserts a call to objc_msgSend when your implementation calls a method. It is not reduced to a static C function call, but dynamic dispatch -- another level of indirection, if you like to think of it that way.
I am little confused finding C style syntax in an Objective-C project (for example below syntax is not how method are defined in Objective-C, by the book). I am clear that this works since the code I have compiles without errors - but I am not sure how and why, this code is regular Objective-C .h,.m files. Can someone explain how this fits in?
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
//use of round brackets
void drawLinearGradient(CGContextRef context, CGRect rect, CGColorRef startColor,
CGColorRef endColor);
// C style syntax for passing params
Also this is very specific around the Core Graphics code that I have seen so far, is it allowed to write regular Objective-C methods like this also or only files with CG code...?
Objective-C is just a superset of C, in the same way as C++. (Both were originally implemented as preprocessors that convert the code to straight C code.) Objective-C method calls are translated to calls to the C function objc_msgSend() (and its variants) and it's possible (though tedious) to call it directly.
The gory details are spelled out here:
https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html
Core Graphics is a C API, not Objective-C. Since Objective-C is a superset of C, any valid C code will compile just fine in .m files.
Objective-C is a superset of C, so you can define plain old C functions in a .m file, and you can call plain old C functions in a .m file using the normal C syntax.
The CGColorSpaceCreateDeviceRGB function is a plain old C function. It is part of the Core Graphics framework (also known as Quartz 2D), which has a pure C API - the API only uses plain C, not Objective-C.
You cannot define Objective-C object methods using plain old C function syntax - you must use Objective-C method syntax. And you should not try to send messages to Objective-C objects using plain old C syntax - you should use the Objective-C message sending syntax (the square brackets).
objc supports standard C that why you find c code in objc project.
As for the framework provided by Apple, if it has coreprefix,like CG standing for core graphic, it usually means it is written in C.
Thank you to Yuji for answering another question I had and pointing me to this article about dynamic ivars in Objective-C.
However, as explained in my other question the sizeof operator now behaves inconsistently. In short, sizeof will not take into account dynamic ivars from outside the class .m file but will take them into account inside the .m file after the #synthesize declarations that create the dynamic ivars.
So my question is does this break the idea that Objective-C is a strict superset of C?
No. All valid C code remains valid Objective-C code with the same meaning it has in C, so Objective-C is still a strict superset. Keep in mind that a superset is allowed to have features not found in a subset — that's the whole reason Objective-C can have all the additional capabilities and syntax that it does while remaining 100% C-compatible.
What this does affect is the implementation detail that Objective-C classes are essentially C struct types with a set of functions that act on them. Note that similar functionality to objC_setAssociatedObject() could be implemented for a CoreFoundation-style pure C struct without changing the C language itself at all — and it would have the similar side effect of making sizeof() not give a fully "accurate" idea of all the data the struct encompasses.
No. If you run Objective-C code through a C compiler it never would have compiled anyway. If you run C code through an Objective-C compiler it will behave exactly as if you had run it through a C compiler (barring compiler bugs).
If you ever find yourself writing sizeof(MyObjectiveCClass) you are almost certainly doing something horribly wrong that will be completely broken.
I'm trying to make a Lua compiler for Mac OSX with an interface written in Objective-C and the Lua source code written in C.
You already are combining C and Objective C. No extra effort is needed.
Objective-C is a proper superset of C. Any C you write in an Objective-C file is perfectly valid.