pointer or not?

kensuguro
Unregistered
 
Post: #1
still learning... I'm having trouble understanding when to declare a variable as a pointer, or not. Is it one of those things you just "memorize", without much theory behind it? None of my books seem to tell me "why" a certain object was declared as a pointer, some not... It looks to me like some things (like NSColor) have to be pointers because that's just the way things were built to work..

sorry to be flooding with these tiny questions.. ya know, is there a more active board for all things cocoa? It feels a bit awkward asking these things when it seems I'm the only newbie around here..
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #2
Pointers are not as difficult as it seems. By rule of thumb, whenever you allocate memory dynamically, as opposed to using the stack, you need to use a pointer. All Cocoa objects are allocated dynamically, hence you must _refer_ to them through pointers. Objects allocated on the stack are destroyed when the current block is exited, and you can no longer use them, say in another function. If you pass on the pointers though, you can still refer to your objects without having to create a new one all the time. Hope that makes some sense Smile
Quote this message in a reply
Member
Posts: 153
Joined: 2004.12
Post: #3
Anything thats a structure like NSPoint, or NSRect you can use like:

NSPoint myPoint;
myPoint.x = 0;
myPoint.y = 15;

NSSize mySize;
mySize.width = 10;
mySize.height = 20;

NSRect myRect;
myRect.origin = myPoint;
myRect.size = mySize;

Without any need for pointers. Generally you wouldn't create a pointer for any type of structure unless your using dynamically allocated arrays.

On the other hand any Obj-C Class that you use like:

NSArray *array = [[NSArray alloc] init];
[array release];

Needs to be defined as a pointer.

So basically you need to know wether your working with a structure or a class. Right clicking on the type of whatever variable and using "Jump to definition" is the easiest way of finding out. So for example if i dont know whether to use a pointer for NSColor, i would go:

NSColor myVar;

Right click on NSColor -> jump to definition -> if i see typedef NSColor i know its a structure otherwise if i see @interface I know its a class. In this case its a class so i change myVar to *myVar.

I hope thats what you where asking.

There was a long silence...
'I claim them all,' said the Savage at last.
Quote this message in a reply
kensuguro
Unregistered
 
Post: #4
aha! great explainations, thanks. It's alot clearer now that I know WHY there's a difference.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #5
After quite a long time of actionscripting (I know, not a programming language), I have started to learn Objective C. In search for the answer on pointers presented here, I found this interesting advice:

Quote:Right clicking on the type of whatever variable and using "Jump to definition" is the easiest way of finding out.

When I control click it doesn't say "Jump to definition". There is the option "find in API reference" and "find in documentation", but I'm not sure whether either of those is useful. Am I using a different version of XCode or what?
Quote this message in a reply
Member
Posts: 100
Joined: 2006.05
Post: #6
You also want to use pointers when you don't want to keep a copy of an object, just a kind of reference to it. For example, if you have a general object structure in your game (which can be balls, cubes, goats, etc.), you'd want a pointer to store the model (or sprite). There's no reason for you to have 40 copies of the goat model if you can use one of them and draw it several times. In this case, your object structure would have a Model* member that identifies what kind of object it is. This is a specific example, but almost every time I've used a pointer (other than in dynamically allocated arrays/objects) it has been something analogous to this. Hope that helps.
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #7
Chrono Wrote:When I control click it doesn't say "Jump to definition". There is the option "find in API reference" and "find in documentation", but I'm not sure whether either of those is useful. Am I using a different version of XCode or what?

By far, one of the most handy features in Xcode is to be able to simply hold down command and double-click on something to jump to its definition. Also very useful to hold down option and double-click to search through documentation for it. I use those two shortcuts *all* the time. I don't think I could live without them anymore.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #8
Thanks a lot, Nevada and AnotherJake. The command-clicking will be especially useful, but it's really good to know about a reason for pointers, especially for making games I think, where you often reuse a model.
I don't know quite yet WHY pointers are the way to go (for not making copies), but I'm sure I'll find out over time.
Thx again!
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #9
Chrono Wrote:I don't know quite yet WHY pointers are the way to go (for not making copies), but I'm sure I'll find out over time.
If you have a chunk of memory being used up by a data structure or whatever, let's say 2 MB for the sake of discussion, instead of copying that data and passing it to whatever method or function, wouldn't it make sense to simply pass the memory address instead? If I wanted you to work on my house I wouldn't ship my whole house to you, I'd just give you my address and you can come over here and fix it! It is sort of the same concept with pointers. A pointer is nothing more than a memory address which we say, "points" to the first byte of a chunk of memory.

Pointers are a *crucial* concept in programming, so you'd be well-advised to spend as much time as it takes to understand it. It's actually very simple once the light-bulb turns on. I remember it took me a long time to grasp pointers way back in the day, but you have to know it.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #10
I did get the point of the house-idea, but I don't know why normal variables copy the information. I do have an idea, but I'm not sure whether it's correct.
An abstract example:

a = anObject
b = a
c = a
Does this mean that anObject ends up being copied into a, b, AND c?
And if I'd use *a instead of a (everywhere), that "anObject" would be only in a, with references to it for b and c?

Thanks in advance!
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #11
Chrono Wrote:a = anObject
b = a
c = a
Does this mean that anObject ends up being copied into a, b, AND c?
Yes.

But you also need to realize that anObject is actually just a pointer, believe it or not, so all you're copying is a pointer (it's adress), not the whole object. If a, b and c are of type void* or id it'll compile. And instead of [anObject doSomething], you could use [b doSomething] instead. We don't usually do that with objects though, so don't let yourself get confused by what I'm saying here. I'd say stick to learning how pointers are used with malloc and primitive data types like floats and ints, etc.

Quote:And if I'd use *a instead of a (everywhere), that "anObject" would be only in a, with references to it for b and c?
No (but I'm not entirely sure I understand you here). Again, like I said above, all that was copied into `a' was a pointer, not the data which makes up anObject. So a = b = c = anObject which will mean that all of them are pointers to anObject.
Quote this message in a reply
Member
Posts: 100
Joined: 2006.05
Post: #12
Another good reason is when you have a piece of data that needs to get modified universally. Let's say it becomes autumn, and all your trees are losing their leaves. If you had copies of the tree model, you would have to search through the list of all your objects and find out which ones are 'trees' and change their model. With a pointer, you can change one model and know that every tree is going to be consistently modified. Pointers are a good way to keep objects up to date without having to modify every one.

Speaking of trees. Let's say you have a branch and a leaf object. The branch object will probably want to contain all of its leaves (no pointers). But the leaf will also want to contain, somehow, what branch it is connected to (i.e. it should have some kind of 'parent' object). It makes no sense to keep a copy of branch in leaf, that would lead to infinite recursion (branch contains leaf which contains branch which contains leaf...) In this case you would use a pointer to the parent branch in the leaf.
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #13
AnotherJake,
Quote:
Quote:Quote:
And if I'd use *a instead of a (everywhere), that "anObject" would be only in a, with references to it for b and c?
No (but I'm not entirely sure I understand you here). Again, like I said above, all that was copied into `a' was a pointer, not the data which makes up anObject. So a = b = c = anObject which will mean that all of them are pointers to anObject.
Then what is the difference between:
a = anObject
and
*a = anObject
Blink
What I thought it was:
theObject * anObject = [[theObject alloc] init];
creates a pointer called "anObject", that points to "theObject", which is contained in it's .m and .h files. Doing:
theObject anObject = [[etc.]] would copy the entire "theObject" (or doesn't this work at all)?
I hope you can help me, but otherwise I'll keep reading (Ebook "Learning Cocoa With Objective-C"). I guess it's all a long process, I have to get used to the ideas, and in the end I'll hopefully understand.

Nevada, thanks for your help, I'm sure it will be useful once I get how pointers are assigned, work, etc. (as opposed to normal variables).
Quote this message in a reply
Member
Posts: 245
Joined: 2005.11
Post: #14
Quote:Then what is the difference between:
a = anObject
and
*a = anObject
The first one won't compile. If you did the same thing with ints (for example) it would work exactly as you describe. But with classes in objective-C, objects can only be allocated dynamically,, so they are always alocated to a pointer (or to an id, which is really a pointer anyway).
To clarify:
Code:
id object1; //this is ok
NSObject *object2; //this is also fine
NSObject object3; //this is very bad.

object1 = [[NSObject init] alloc]; //this creates a NSObject and puts its address in object1
object2 = [[NSObject init] alloc]; //this does the same
[object2 release]; //it is a good idea to do this before the line below to avoid a memory leak
object2 = object1; //this makes the variable object2 point to the same object as object1
[object2 retain]; //it is a good idea to do this after copying pointers to objects

int number1; //this is an int
int *number2; //this is a pointer to an int

number2 = &number1; //number2 is now a pointer to number1
number2 = number1; //this makes number2 a pointer to unallocated memory and will cause a crash if you try to use it
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2007.08
Post: #15
OK, thanks a lot backslash, the examples were really helpful.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  memory pointer tricks? Toontingy 2 4,093 Mar 31, 2009 02:35 AM
Last Post: Ingemar
  pointer cleanup questions kendric 7 4,420 Mar 29, 2009 07:48 PM
Last Post: kendric
  My AnimationManager didn't like being a pointer. milkfilk 6 3,809 Mar 24, 2007 10:03 PM
Last Post: unknown
  Pointer-related woes (C/C++) sealfin 2 2,585 Jan 18, 2006 01:22 PM
Last Post: sealfin
  Hide Mouse Pointer JonTrainer 9 7,138 Nov 10, 2005 10:46 AM
Last Post: Jordan