Use of Pointers in Objective-C

Question

Possible Duplicate:
what is the point of pointers in objective language

I am confused as to when and why pointers are used in Obj-C code. I am new to Obj-C and have a good grounding in C++ from an intro course at my university.

NSDate *now = [NSDate date];

Why is a pointer used here (and what exactly is its purpose?), and not here...

NSUInteger arrayLength = [<some array> count];

I am much more comfortable with the second example, but the first is still puzzles me.

possible duplicate of [what is the point of pointers in objective language](http://stackoverflow.com/q/10582250/), [ObjC and Pointers](http://stackoverflow.com/q/5203284/), [Understanding Pointers](http://stackoverflow.com/q/9746683/), [Why the objects we create are pointers](http://stackoverflow.com/q/3044292/), [Asterisk usage in ObjC](http://stackoverflow.com/q/2035994/), [Using pointers in ObjC](http://stackoverflow.com/q/9123079/), [When and when not to use pointers in ObjC](http://stackoverflow.com/q/5074369/), [etc.](http://stackoverflow.com/search?q=%5bobjc%5d%20why%20pointers) — jscs, Jul 18 '12 at 18:42

score 4 · Answer 1 · answered Jul 18 '12 at 18:42

It's the wording of the typedefs of Apple which are confusing.

NSUInteger

is just a fancy typedef for unsigned int; therefore it's a scalar type and not an object; you don't need a pointer to it in general for such a simple use case.

However,

NSDate

is a Foundation class; it means that its instances are proper Objective-C objects. As you probably know, Objective-C is a fully dynamic language: no static instances of classes are permitted, so every object is essentially a pointer (well, rather the allocated memory behind the pointer). So when you work with Objective-C objects, you always need a pointer to them.

Christian Stieber · Answer 2 · 2012-07-18T18:53:43.180

Well, there are a few fundamental differences between Objective-C and C++. In Objective-C, there is actually a "generic object" (type "id"), and you can pass objects around without worrying about classes.

One of the implementation details that makes this possible is that Objective-C doesn't have "static" objects; all objects are created through the equivalent of "new" and are accessed through a pointer (string literals might be different, but they are still of type "NSString*"). It's just the way it is in Objective-C; you simply cannot have an "NSString MyString".

Because of this, the whole "objects are just objects and the compiler doesn't actually what you're dealing with" is possible because all objects are just simple pointers -- they are all the same size. The compiler can pass them around without knowing what they are, you can store them in containers without the containers knowing what they are etc.

Objective-C and C++ may both be "object-oriented" extensions of C, but they are quite different nonetheless.

EDIT: you can write stuff like "NSString* MyString" so the compiler knows what kind of object it is dealing with, but that's just convenience: you can still put other objects into that pointer (and, in fact, since the "new" equivalent usually returns id, one of the more common mistakes that I make is to "new" a different class from what the pointer says) On the positive side, the compiler will warn you if you assign e.g. an NSWindow* to MyString, and it will also warn you if you call "open" on MyString. However, this is just an added benefit from the compiler; you could just as well declare everything as "id", or cast away the warnings.

id is not really a generic object. It's only a pretty way to say `void*` — Sulthan, Jul 18 '12 at 18:48
No, it's really a generic object, @Sulthan. It's `typedef struct objc_object { Class isa; } *id;` -- you can only put an object in there. Try, for example: `int i = 10; void * v; id o; v = &i; o = &i;` — jscs, Jul 18 '12 at 18:56
@Sulthan now head to /usr/include/objc/runtime.h and watch out for `typedef struct objc_object *id;` — , Jul 18 '12 at 19:15

Use of Pointers in Objective-C

2 Answers2