6

If we type 

MyObject *obj = [[MyObject alloc] init];

"obj" is a pointer to the memory address.

...When we create an int, we type: 

int x = 10;

Why don't we type? 

int *x = 10;

The question is, why do we need a pointer to object and not int, float, etc...

Popeye
  • 11,839
  • 9
  • 58
  • 91
BlackMouse
  • 4,442
  • 6
  • 38
  • 65
  • 1
    You can point to an int. Just `malloc(sizeOf(int))`. Take a read through of some C documentation, and [this](http://stackoverflow.com/questions/162941/why-use-pointers). If it doesn't answer your question, then consider that Objective-C would lose the majority of its memory dynamism if it's objects were stack allocated – CodaFi Mar 28 '13 at 08:07
  • possible duplicate of [Objective C: Memory Allocation on stack vs. heap](http://stackoverflow.com/questions/4326965/objective-c-memory-allocation-on-stack-vs-heap) – CodaFi Mar 28 '13 at 08:15
  • http://forums.macrumors.com/showthread.php?t=625899 – iPatel Mar 28 '13 at 08:18
  • `int`, `float` etc.. are scalar data types - also called primitives (when talking C or Objective-C). They do not have to be allocated on the heap (alloc/init/new) but may be allocated on the stack. – Till Mar 31 '13 at 00:41

5 Answers5

9

Efficiency.

Moving an int from one place to another is easy. Moving an object needs a little bit more work from the CPU. Moving the address of an object is as easy as moving an int.

In plain C, it is common to handle pointers to structs for the same reason. C makes it easy with the -> operator.

Community
  • 1
  • 1
mouviciel
  • 66,855
  • 13
  • 106
  • 140
  • I would also say that the heap is the only place where memory can be safely reference counted, which is a huge feature of ObjC – CodaFi Mar 28 '13 at 08:21
  • @CodaFi - Heap, stack and reference counting are an epiphenomenon. When you declare an int variable, you don't need to care where it is actually located or whether it is correctly deallocated. you care only about its scope and the language silently handles implementation details. The same could be done with objects. – mouviciel Mar 28 '13 at 08:31
  • @mouviciel The same could be done, and is with locals, but for permanence and reference management in ObjC specifically, the language doesn't handle a thing, it's all the compiler, and that can be turned off at the flip of a flag. Reference counting has not gone away, it's merely been abstracted away. To call it an epiphenomenon in a language that still (under the hood, now) relies on explicit runtime retains and releases is spurious. – CodaFi Mar 28 '13 at 08:34
  • It could be exactly the other way around with efficiency: short-lived local stack-based objects would be [faster than allocating them on the heap](http://stackoverflow.com/questions/161053/c-which-is-faster-stack-allocation-or-heap-allocation)? – zoul Mar 28 '13 at 08:46
  • @zoul - Whenever you send a message to an object, you actually pass it as argument to a function. You pass it either by value and a copy is necessary or by reference and you fall back to an object pointer. – mouviciel Mar 28 '13 at 08:51
  • 1
    @zoul precisely. That's why blocks are initially allocated on the stack (that, and they tend to be short-lived), then get copied onto the heap if they need to outlive their function's scope. – CodaFi Mar 28 '13 at 08:53
  • @mouviciel: That’s just an implementation issue, you could have stack-based objects and automatically use a pointer to the stack when messaging them. – zoul Mar 28 '13 at 08:53
  • @zoul - Exact. And you end up with object pointers for efficiency purpose. – mouviciel Mar 28 '13 at 08:54
  • I don’t understand the language implementation enough, but it seems to me that allocating an object on the stack (which is *fast*) and then using a pointer to it behind the scenes when messaging the object would be faster than allocating the object on the heap (*slow*) and having the pointer right at hand? – zoul Mar 28 '13 at 08:58
  • @zoul - The OP's question is not about stack vs heap or memory allocation, it is more conceptually about why int data is simply that: int data, and why object data is one indirection level away the actual object data. A local int is on stack, a global int is on heap. Why wouldn't it be possible to declare an object the very same way? The only conceptual reason I see is efficiency. – mouviciel Mar 28 '13 at 09:04
  • Well, and that’s not really true. If you have stack-based objects in the language (like in C++) then you can choose the more efficient storage for the object, and that’s not always the heap. If it’s a small one-shot local object, storing it on the stack would be more efficient. – zoul Mar 28 '13 at 09:11
  • 1
    Ah, I think I know where we don’t understand each other. There are really two independent things, as you say: allocating on the heap vs. stack and allocating “statically” (without a pointer) vs. allocating through a pointer. Since stack-based allocation is usually done without a pointer, I have conflated the two (stack-based = without a pointer). But as you say, you could have stack-based allocation and still use pointers for objects for efficiency. Sorry for being so obtuse. – zoul Mar 28 '13 at 09:24
  • @zoul - Thank you for clarifying, now I understand better our points. – mouviciel Mar 28 '13 at 09:42
2

There are languages where you can create objects “without a pointer”, on the stack. C++, for example. One great thing about having objects on the stack is that they get automatically deallocated when the scope ends, which helps with memory management. It’s also faster.

One bad thing about having objects on the stack is that they get automatically deallocated when the scope ends and the stack disappears. And since objects are usually longer-lived than local variables, you would have to copy the object’s memory somewhere. It’s entirely possible, but it complicates matters.

And it’s not just the memory lifecycle that’s complicated with stack-based objects. Consider assignment, foo = bar for two object types. If the objects are always pointers (Class*), you just assigned a pointer and got two pointers to the same objects; easy. If foo is stack-based (Class), the assignment semantics starts to get blurry – you could well end with a copy of the original object.

Introducing a rule that all objects are allocated on the heap (“with pointers”) is a great simplification. And as it happens, the speed difference doesn’t matter that much, and the compiler can now also automatically insert code to deallocate heap-based objects after they go out of scope, so it’s generally a win-win situation.

Community
  • 1
  • 1
zoul
  • 102,279
  • 44
  • 260
  • 354
  • Plus, IIRC, the stack is a fixed memory size, while the heap can grow to a certain extent to accomodate new objects. That means creating large objects would quickly lead to an error. – borrrden Mar 28 '13 at 08:44
1

You can have pointer for int, float as well.

Objects are created on heap. To access it, you need the address. Thats why they are of pointer types.

Apurv
  • 17,116
  • 8
  • 51
  • 67
  • 1
    I guess he really wants to know why we heap-allocate in Objective-C, rather than that we just *do* – CodaFi Mar 28 '13 at 08:13
  • yeah, why do we allocate an object on the heap and int on the stack? – BlackMouse Mar 28 '13 at 08:15
  • To achieve the flexibility that Obj-C offers. – Apurv Mar 28 '13 at 08:15
  • 2
    @Apurv If that were any kind of reasoning for pointing to an object, then ints would be objects. After all, why should objects get all the fun if I can heap allocate an int or a float like you said? Include that in your answer – CodaFi Mar 28 '13 at 08:16
1

Because that is the nature of an object.

Objective-C is directly derrived from C. That is why objects are referred to as pointers. An int-type variable of the size of an memory address is a pointer. In the end, an object in memory is not much different from an struct in memory.

However, when working in Objective-C it is advisable to think of these variables as references of objects rather than pointers to an object's memory areas. Think of them like Java does and do not spend much thoughts on how the system manages the references. There are far more important things to think of such as alloc/retain vs. release/autorelease or following the much easier ARC rules respectively.

BTW: 

MyObject obj;

That would declare an object, not a pointer. It is not possible in Objective-C (afaik) and certainly not reasonable. But if it was reasonable and possible, that is what the syntax would look like. 

int *x;

That does create a pointer to an int. For using it you would have to allocate memory and assign its address to x. Rarerly reasonable in Objective C either but quite useful in standard C.

Hermann Klecker
  • 14,039
  • 5
  • 48
  • 71
  • You could also argue that C++ is a direct descendant of C and it has stack-based objects. – zoul Mar 28 '13 at 08:38
1

its the difference between objects being on the stack or the heap. going int x = 10 x is now on the stack. int *x = 10 is just simply wrong (well most likely not what you want) since that is declaring a pointer to address 10 whatever that may be. you would want int *x = malloc(sizeOf(int)); as CodaFi suggested. that will allocate memory on the heap of the size of an int.

going MyObject *obj = [[Myobject alloc] init]; the compiler behind the scenes is allocating your object to the heap for you, but its basically the same principle

Fonix
  • 11,447
  • 3
  • 45
  • 74