iOS When do variable declarations require a "*"?

[jrdoner]

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

 

[Matthew Yohe]

It's not random.

I would recommend reading up on pointers.

 

[cmaier]

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]

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]

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]

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]

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]

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).

 

[firewood]

Objects cannot be allocated on the stack.

Not exactly on-topic, and Apple removed the easy way to do this (which is still mentioned in the GNU Objective C FAQ), but there's still the NSStackBlock trick.

 

[cmaier]

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.

 

[dejo]

I think the OP was looking for a simple rule to tell when a type is a object.

I believe that rule would be: check the documentation for it.

 

[cmaier]

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!"