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.
Related
I recently started a project where I require to do swizzling.
After going through many tutorials I got a question, What is the difference between Implementation and function pointer?
From memory, an IMP is a memory-address just like a function pointer, and can be invoked just like an ordinary C function. However it is guaranteed to use objective-C messaging convention, where:
The first argument is the object to operate on (self).
The second argument is the _cmd (SELECTOR) to be invoked. I believe this is so to support dynamic features, such as ObjC message forwarding where we could wrap the original implementation in a proxy, say to start a transaction or perform a security check, or, for a Cocoa specific example, add some property observation cruft, by magic, at run-time. While we already have the function signature, I could be helpful, in some cases, to know "how did I get here?" with the message signature.
Following arguments, if any, are according to the method contract.
Background as I understand it: Objective-C method invocations are basically a C function call with two hidden parameters (the receiver and the selector). The Objective-C runtime contains a function named objc_msgSend() that allows to invoke methods that way. Unfortunately, when a function returns a struct some special treatment may be needed. There are arcane (some might say insane) rules that govern whether the structure is returned like other values or whether it's actually returned by reference in a hidden first argument. For Objective-C there's another function called objc_msgSend_stret() that must be used in these cases.
The question: Given a method, can NSMethodSignature or something else tell me whether I have to use objc_msgSend() or objc_msgSend_stret()? So far we have found out that NSMethodSignature knows this, it prints it in its debug output, but there doesn't seem to be a public API.
In case you want to respond with "why on earth would you want to do that?!", please read the following before you do: https://github.com/erikdoe/ocmock/pull/41
Objective-C uses the same underlying ABI for C on a given architecture, because methods are just C functions with implicit self and _cmd arguments.
In other words, if you have a method:
- (SomeStructType)myMeth:(SomeArgType)arg;
then really this is a plain C function:
SomeStructType myMeth(id self, SEL _cmd, SomeArgType arg);
I'm pretty sure you already know that, but I'm merely mentioning it for other readers.
In other words, you want to ask libffi or any kind of similar library how SomeStructType would be returned for that architecture.
NSMethodSignature has a -methodReturnType that you can inspect to see if the return type is a struct. Is this what you're trying to do?
From http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_explain_objc_msgSend_stret.html:
The rules for which struct types return in registers are always
arcane, sometimes insane. ppc32 is trivial: structs never return in
registers. i386 is straightforward: structs with sizeof exactly equal
to 1, 2, 4, or 8 return in registers. x86_64 is more complicated,
including rules for returning floating-point struct fields in FPU
registers, and ppc64's rules and exceptions will make your head spin.
The gory details are documented in the Mac OS X ABI Guide, though as
usual if the documentation and the compiler disagree then the
documentation is wrong.
If you're calling objc_msgSend directly and need to know whether to
use objc_msgSend_stret for a particular struct type, I recommend the
empirical approach: write a line of code that calls your method,
compile it on each architecture you care about, and look at the
assembly code to see which dispatch function the compiler uses.
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 know that in Objective C, every object has first 4 bytes [depending upon type of processor ] as an isa pointer stored in it that tells which class it belongs to and what dispatch table to use to resolve a selector to address of a function.
What I wanted to know was , how are data members stored and accessed in these methods.
self is passed as an implicit object in each function being called.
We use setters n getters to handle data members in other member function as a good practice,
but when we directly refer to a data member in an initializer or an accesor, how are they accessed. Are they replaced by some address at compile time or something else ?
Actually afaik the memory layout is implementation specific, but http://algorithm.com.au/downloads/talks/objective-c-internals/objective-c-internals.pdf should give you a pretty good idea of the inner works of object data and object messaging.
When you use a direct member access, what basically happens is that you're fetching straight from the "struct" that is your actual object. That is, the compiler is basically just adding an offset to the address of your object/struct and reading the contents of that memory address.
Maybe I should add that this is reverse engineered from XCode and not written in any specification I can find, so depending on this behavior is most likely a bad idea. Since external access to the iVars is not allowed, the decision is basically up to the compiler and could be changed at any time.
Edit: as #FrederickCheung points out, Objective C 2.0 may have changed this behavior.
It's not as simple as a compile time offset calculation, at least not in objective C 2.0 on the 64bit OS X and iOS runtimes. These support stuff like superclasses changing their instance variable layout without breaking subclasses that were compiled against the old layout by adding a layer of indirection.
The runtime api docs describe the API one can use to set instance variables and so on but doesn't elaborate on their implementation.
I come from a PHP/Javascript background where things are stored in a variable directly in most cases, where we also had Object/Classes/Methods, etc. It was OOP.
Now I'm starting to learn Objective-C. I understand the basics of pointers. But everything is a pointer now. This is the part that I don't get. Why aren't we like in PHP/Javascript with direct assignment? We are still doing OOP afterall.
Thanks
If you look at the semantics of JavaScript and many other OO languages (perhaps including PHP, but I'm not sure and not willing to guess), you'll see that these languages offer the same indirection Objective C offers through pointers. In fact, internally these languages use pointers everywhere. Consider this (JavaScript) snippet:
function f(obj) {
obj.x = 1; // modifies the object referred to directly
obj = {x: 2}; // doesn't affect caller
}
var foo = {x: 0};
f(foo); // passes a pointer/"reference"
// foo.x === 1
It's roughly equivalent to (C as I don't know Objective C) something like this, modulo manual memory management, static typing, etc.:
struct Obj { int x; };
void f(struct Obj *obj) {
obj->x = 1;
obj = ...; // you get the idea
}
struct Obj *foo = malloc(sizeof(*foo));
foo->x = 0;
f(foo);
free(foo);
It's just explicit in Objective C because that language's a superset of C (100% backwards compability and interoperability), while other languages have done away with explicit pointers and made the indirection they need implicit.
In PHP you also work only with pointers but transparently.
Really you using references to objects
The reason why the designers of Objective-C decided to go with using pointers on everything that is an Objective-C object include the following:
So they can deal with behind the scenes memory management without taking away the programmers ability to do so on his own.
Fast Enumeration on objects.
(Perhaps the most important) Gives the ability to have id types that can pass nil(null) values without crashing the program.
To build on the other answers here: in PHP and other languages you are still using pointers. That is why there is still a distinction between passing by reference and passing by value. There are several good sites that help explain the distinction, both in syntax and what it means to pass by either method.
Edit:
Refer to the second link in my post. My interpretation of that information is that PHP passes by value by default. Adding the ampersand in front of the variable during the function call passes a reference (or rather the address of the variable). In essence, passing by reference is passing a pointer while passing by value does a copy of the value completely. They also have different implications on their usage (reference allows modifying the original variable's value, even outside the scope of the function etc).
Objective C is a strict superset and extension of ANSI C, so the native types that could be compatibly added to the language were constrained (perhaps by the original implementation). But this compatibility with ANSI C has turned out to be one of the advantages of using Objective C mixed with the reuse of cross-platform C code.
BTW, OOP and "safety" are nearly orthogonal concepts. They each have different potential costs in terms of consuming CPU cycles and/or eating the user's battery power.
Objects are created using the +alloc method, which allocates space for the new object on the heap. In C, and therefore in Objective-C, the only way to refer to memory on the heap is through a pointer.