Do all functions (as opposed to class/instance methods) in Objective-C use C syntax for both declaration and calling?
well, it really is C. Objective-C is a superset of C, meaning that you can use any C construct you want and the compiler will handle it. Just declare C functions as you normally would, and call them as you normally would.
Yes, they do. Objective-C is built on top of C, so the C syntax is valid.
Related
How could it be possible to call D functions from Objective C? Is such a bridge even possible?
D has limited Objective-C support already: https://dlang.org/spec/objc_interface.html
This thread explains how to do the same from C++: Calling a D function directly from C++
I guess it should not be difficult to do the same from Objective-C code.
Since Objective-C still has all the C stuff, they could call each others functions through the extern(C) interface too, reducing the problem to the solved issue of calling D functions from C.
I am new to Objective-C and I am wondering if it is possible to mix C and pure Objective-C freely. If so, does it have any effects on my program?
Objective-C is a strict superset of C thus C code is a subset of Objective-C code so all C code is also Objective-C code.
Thus you can include any C code in Objective-C.
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.