Objective-C and Pointers

I understand pointers and know what they are and how to declare them. But, the problem is, none of the books, tutorials or guides actually explain why pointers are used.

I come from 开发者_开发问答a PHP background, where pointers are not used. So when I declare a string, I don't use a pointer.

I see pointers being used in header files when creating methods, and I really don't understand why they are there for.

Any help would be appreciated.

I think most of the discussion are done on this topic. you can follow these links

What are the barriers to understanding pointers and what can be done to overcome them?

Why use pointers?

http://ruel.me/blog/2010/11/22/why-use-pointers/

http://duramecho.com/ComputerInformation/WhyCPointers.html

Local variables have automatic duration, meaning they go away when a function exits. When local variables are bound directly to values, the values also must cease to exist when the function exits. PHP uses references (though "alias" is a better match, technically, for what PHP uses) for values that must exist beyond the invocation of a function that creates them, so they can have dynamic duration. It also uses garbage collection (the implementation of which has changed in 5.3) to manage the lifetimes of these values. You don't normally have to use references explicitly, as (true) references are used automatically for class types and references aren't as necessary with value types.

Where PHP has references, Objective-C has pointers, which come from its C roots. Pointers let you dynamically allocate objects so they endure outside the function call chain (i.e. the stack). You can have garbage collection in Cocoa, but that's a newer feature. The previous technique, which is based on reference counting, is still very viable (and the only option in iOS and some non-Apple Objective-C implementations).

Without pointers (or references), objects would live entirely on the stack and would need to be copied when entering or leaving a function. Objects store state; copying an object means the original's state wouldn't be updated when the copy takes some action and alters its state. Sometimes this wouldn't be a problem, whereas other times it would be a fatal flaw. Imagine what would happen with input or output streams if I/O functions could only work on copies.

To add to the existing answers with some context: Objective-C is a strict superset of C. Quite a lot of the language is convention rather than syntax. For example, the use of 'dealloc' to do what a formal destructor does in other languages is just a convention of classes that inherit from NSObject. The compiler doesn't recognise your dealloc method as being in any way distinct from the others.

One of the pragmatic decisions that allows objects to be grafted onto the C runtime is that they always live on the heap, never on the stack. The C mechanism for keeping track of something on the heap is a pointer. As a result, in Objective C you keep hold of all objects by pointer. The autorelease pool then ameliorates the syntactic burden that would result in cases where you really want to act like things are on the stack.

So they're used to keep things on the heap, as already answered. And objects are kept on the heap because memory management relies on convention and because doing so allowed objects to be added to the C runtime with de minimis changes.