iOS When do variable declarations require a "*"?

jrdoner

macrumors newbie
Original poster
Nov 26, 2009
12
0
Florida
I have been working with IPhone/XCode now for about six weeks, and I came to this from a non-C programming background. Although I see that most variable declarations are to a pointer, e.g., NSString *myString, I note that simple non-object things like integers are just declared as int myInt.

But there seem to be some objects that are declared in the nonpointer style as well: I think CGPoint is one of them.

So is there any hard and fast rule that distinguishes these cases, or is it sort of random?

Thanks in advance for any help.

John Doner
 

cmaier

macrumors P6
Jul 25, 2007
16,087
12,356
California
There's no easy way to tell just from the name of the type/class. You need to know how things are typedef'd. You can use xcode to "jump to definition" or look up the type in the reference.
 

admanimal

macrumors 68040
Apr 22, 2005
3,531
2
Typedefs have little to do with it. Generally speaking, and Cocoa or UIKit classes are always used via pointers (i.e. with a *). Primitive types depend on the use, as do most other types.

But yes...read up on pointers. Nothing is random in programming.
 

cmaier

macrumors P6
Jul 25, 2007
16,087
12,356
California
Typedefs have little to do with it. Generally speaking, and Cocoa or UIKit classes are always used via pointers (i.e. with a *). Primitive types depend on the use, as do most other types.

But yes...read up on pointers. Nothing is random in programming.
The point is, a beginner won't know the difference between a typedef and a class without checking the definition.
 

firewood

macrumors 604
Jul 29, 2003
7,735
956
Silicon Valley
So is there any hard and fast rule that distinguishes these cases, or is it sort of random?
It's random.

You have to look at the definition of each variable type to be sure.

Historically, the storage for "small" items was declared directly on the stack, global heap, or as some number of bits inside an object, and thus be accessible directly by a compile-time variable name (no "*"). Whereas the storage for "larger" or variable sized items was usually requested from a memory allocation pool, and thus be accessed via a pointer dereference "*" (or double dereference "**" with Carbon Handles) from some name.

However "small" and "larger" are judgment calls by the implementers, and thus can be random depending on who got to last word on documenting that item's type definition. You sometimes have a pointer for something tiny that's only a few bits, or a static variable for some monsterously huge struct larger than most big objects. Although it breaks memory management rules, it's even possible to allocate certain types of Obj-C objects on the stack and thus be able to refer to them both with and without indirection.

So the only absolute way to make sure is to check the definition for each variable type name.
 

robbieduncan

Moderator emeritus
Jul 24, 2002
24,764
133
Harrogate
It's not random. At all. Objects cannot be allocated on the stack. Non-objects can (although, depending on your usage, you could still want a pointer to them). The example given by the OP of CGPoint is not an object.
 

Luke Redpath

macrumors 6502a
Nov 9, 2007
731
6
Colchester, UK
Generally: objects are pointers, primitives, enums and structs are not. In your example, CGPoint is a struct. Apple use structs for simple structures in various frameworks, especially CoreGraphics (CGRect is another one).
 

cmaier

macrumors P6
Jul 25, 2007
16,087
12,356
California
It's not random. At all. Objects cannot be allocated on the stack. Non-objects can (although, depending on your usage, you could still want a pointer to them). The example given by the OP of CGPoint is not an object.
That doesn't help the OP. He can't look at th name of a type an say "ah, this can't be allocated on the stack, so it must be a pointer." you've reversed the OPs problem. He doesn't know, just by looking at the name of something, whether it is an object (in which case it has certain properties) or not. So, in that sense, it appears random. In other systems, you can tell whether a return type is a pointer or not by naming convention, for example by the inclusion of Ref or Ptr in the name. I think the OP was looking for a simple rule to tell when a type is a object.
 

cmaier

macrumors P6
Jul 25, 2007
16,087
12,356
California
I believe that rule would be: check the documentation for it.
Yeah, I agree, which is what I said. But people started with "you can tell the pointers because those are the ones that can't be passed on the stack!" and "you can tell the pointers because those are the ones that are pointers!" and "go look up pointers!"
 

Similar threads

Register on MacRumors! This sidebar will go away, and you'll see fewer ads.