I'd like to convert Objective C code into plain C. I can do this by hand rather easily. For example this Objective C code:
[object method];
could be converted to something like:
SEL method = sel_registerName("method");
objc_msgSend(object, method);
However this is kind of tedious, especially for larger files. It seems clang should be able to generate this C code pretty easily. Is there a way I can convince it to do so?
Short answer: No.
Longer answer: clang supports -rewrite-objc, but you are almost certainly not going to like the results.
Related
(I'm a cocoa beginner and ) I'm wondering why we should do:
NSLog(#"this is the variable value: %d",variable);
and not something like this:
[NSLog outputThis:#"this is the variable value: %d" param:variable];
I agree this is pretty confusing when you're starting out. The main reason is that the NSLog method, like many others in Core Foundation, is a C-based API, rather than an Objective-C API. C-style functions look like this myFunction(myParameter1, myParameter2).
All the GUI stuff you're probably used to [UIView presentModalViewController:] etc is based around an Objective-C API, with the square brackets that you've seen for functions (called selectors in Obj-C) . The Objective-C language sits on top of C, so you will find both styles in most apps.
NSLog may seem like a class, but it isn't.
NSLog is a FoundationKit function for printing debug statements to the
console. It is defined in NSObjCRuntime.h:
void NSLog(NSString format, ...);
There is a good amount of information here: http://cocoadev.com/wiki/NSLog
EDIT: As #fyngyrz pointed out, the page is dead. So here is a wayback-machine version of the page from 2012
As I understand it, NSLog isn't an Objective C function but a C function built into the foundation of Cocoa. Therefore it conforms to basic C functions with variadic arguments.
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.
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).
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.