When do variable declarations require a "*"?

Discussion in 'iOS Programming' started by jrdoner, Nov 30, 2009.

  1. macrumors newbie

    Joined:
    Nov 26, 2009
    Location:
    Florida
    #1
    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
     
  2. macrumors 68020

    Joined:
    Oct 12, 2006
    #2
    It's not random.

    I would recommend reading up on pointers.
     
  3. macrumors G3

    Joined:
    Jul 25, 2007
    Location:
    California
    #3
    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.
     
  4. macrumors 68040

    Joined:
    Apr 22, 2005
    #4
    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.
     
  5. macrumors G3

    Joined:
    Jul 25, 2007
    Location:
    California
    #5
    The point is, a beginner won't know the difference between a typedef and a class without checking the definition.
     
  6. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #6
    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.
     
  7. Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #7
    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.
     
  8. macrumors 6502a

    Joined:
    Nov 9, 2007
    #8
    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).
     
  9. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #9
    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.
     
  10. macrumors G3

    Joined:
    Jul 25, 2007
    Location:
    California
    #10
    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.
     
  11. Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #11
    I believe that rule would be: check the documentation for it.
     
  12. macrumors G3

    Joined:
    Jul 25, 2007
    Location:
    California
    #12
    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!"
     

Share This Page