Static Field?

Discussion in 'Mac Programming' started by teguh123, Apr 7, 2011.

  1. teguh123 macrumors member

    Mar 22, 2011
    Let's see a sample straight from

    @interface Run : NSManagedObject {
        NSInteger processID;
    @property (retain) NSDate *date;
    @property (retain) NSDate *primitiveDate;
    @property NSInteger processID;
    Now, that processID is static in a sense that we have that as member rather than a pointer to processID

    Will this work only on primitive type like NSInteger?

    Given that it's static, we do not need to dealloc it. So why not make every member static?

    They'll be on the heap anyway instead of the stack because the Run object is in the stack
  2. jiminaus macrumors 65816


    Dec 16, 2010
    You're using the word static rather incorrectly. A static member, if would have any meaning in the context of object, would mean a member that exists at the class-level as opposed to the object-level.

    In C++ you can have direct members which are objects. You do not need to have indirect members which are pointers to objects. And you'll have the added advantage of no having to write a destructor.

    In Objective-C you always have to use pointers to objects.

    The following code will cause a compiler error anywhere it exists, assuming MYClass is an Objective-C class.

    MYClass myObject;
    It always has to be

    MYClass[b][color=red]*[/color][/b] myObject;
  3. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    The processID variable isn't static. Not in the C sense, nor in the Objective-C sense (which is identical in every way to the C sense).

    You did not mean "static", because that's not what static means. What you meant is "not referenced by a pointer".

    The reason you can do this with all types EXCEPT objects is very simple:
    because that's how the Objective-C language is defined.

    There are no direct object variables, only indirect object variables, i.e. pointers to objects. C++ is different because the language was defined differently. Java is different because it was defined differently. When you learn each language, you must learn it on its own terms, not on the terms you wish it had if you were the language designer.

    This must be a typo, because all Objective-C objects are in the heap, never on the stack. Object references (i.e. pointers to objects) can be in the heap, on the stack, or in a register. It is never true to say "the Run object is in the stack".
  4. admanimal macrumors 68040

    Apr 22, 2005
    The correct term for a non-pointer referenced object is statically allocated not static, which as others have pointed out has a different meaning. Statically allocated objects are not allowed in Objective-C.
  5. Sydde macrumors 68020


    Aug 17, 2009
    I can think of a few reasons for not allowing statically allocated objects. Foremost is the class clusters like NSString or NSNumber: since the returned object is a subclass of the umbrella class, can we be sure of its memory footprint? Remember, statically allocated objects defined as ivars would have to reserve exactly the right amount of memory (or at least a big enough block) at compile time. This means any change in the footprint of the ivar class means your code must be recompiled against the new framework or it runs the risk of failure.

    Which is the second point: using only pointers makes it much easier to redesign frameworks without having to worry about internal object changes affecting code the uses those frameworks. In addition, frameworks can be distributed to other users (programmers) without revealing internal information about the objects. I think this is a good thing.

    Some objects rely on receiving -dealloc, which you might be able to just skip over if you just had their context embedded in your object. NSFileHandle is one that comes to mind. NSWindow is another that I think would fare badly if its context were allowed to just vanish this way.

    Then you have things like NSScreen, NSWorkspace, NSFontPanel, these things simply cannot be statically allocated. For that reason alone, using pointers for all objects makes sense. This little bit of consistency helps. If memory management is a big hassle, just use GC.
  6. teguh123 thread starter macrumors member

    Mar 22, 2011
    You are correct

    NSNumber is in a sense not object isn't it. It's like VB6. Primitve types are "statically allocated" (even if that means in the heap). While object types are always on the heap.

    The difference is in VB6 and what we have are hybrid smart pointers smart references.

    How do we know that a class can be statically allocated and what class cannot?

    Looks to me that NSNumber can be statically allocated where most other objects, like NSObject cannot right?
  7. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    Wrong. NSNumber is an object type. Specifically, NSNumber is a class.

    NSInteger is a non-object type. NSInteger is not the same as NSNumber. Accuracy is important.

    Mostly correct.

    Variables defined as primitive types, or composites composed of them like structs or arrays, can be statically allocated, OR they can be dynamically allocated. Dynamically allocated means created at run-time. "Statically allocated on the heap" is nonsense.

    A class can NEVER be statically allocated.

    If you mean "How do we know that a typename can be statically allocated", then the answer is the above sentence: a class can never be statically allocated. All other types can be dynamically or statically allocated.

    If you want to know which types are typedefs, see this:

    If you want to know if a specific type-name is a class name or a typedef, look it up in Xcode's reference documentation. You can usually just enter the type-name in the proper search box and it will tell you the defining header. From there you can determine if the name is a class-name or a typedef.

    Wrong. NSNumber is a class. NSInteger is a typedef. Accuracy is important.

    You really need to review the fundamental documentation.
  8. admanimal macrumors 68040

    Apr 22, 2005
    And forget everything he knows about Visual Basic.
  9. firewood macrumors 604

    Jul 29, 2003
    Silicon Valley
    Prehistoric Objective C implementations allowed creating objects on the stack, IIRC. The current Apple run-time does not.
  10. gnasher729 macrumors P6


    Nov 25, 2005
    NSNumber is absolutely an object. Documentation says: "Inherits from NSValue : NSObject. Conforms to NSCoding (NSValue), NSCopying (NSValue) and NSObject (NSObject). "

    Being an object is the whole point of NSNumber, so you can put it into NSSet, NSArray etc. or pass it to the thread-handling methods that require an NSObject parameter.
  11. Sydde macrumors 68020


    Aug 17, 2009
    It does seem almost aggravating that Apple chose the prefix nearly all the components of the Cocoa frameworks with "NS".
    • NSInteger is a primitive
    • NSNumber is an object
    • NSRect is neither (it is a struct)
    • NSOrderedAscending is a constant
    With a little practice and experience, one can quickly figure out what kind of thing the NS- label refers to, but for a beginner, it is pretty confusing. Hence, XCode provides you with a handy little palette called "Research Assistant".

    Is a "palette" a feminine pal?
  12. admanimal macrumors 68040

    Apr 22, 2005
    Well, since the NS stands for NeXTStep, you should probably blame NeXT for that.

    In any case, the prefix isn't supposed to indicate anything about type, it's just there to indicate which framework you're working with and/or avoid namespace collisions.

Share This Page