Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

teguh123

macrumors member
Original poster
Mar 22, 2011
62
0
Let's see a sample straight from

Code:
@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
 

jiminaus

macrumors 65816
Dec 16, 2010
1,449
1
Sydney
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.

Code:
MYClass myObject;

It always has to be

Code:
MYClass[b][color=red]*[/color][/b] myObject;
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
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.


They'll be on the heap anyway instead of the stack because the Run object is in the stack
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".
 

admanimal

macrumors 68040
Apr 22, 2005
3,531
2
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.
 

Sydde

macrumors 68030
Aug 17, 2009
2,552
7,050
IOKWARDI
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.
 

teguh123

macrumors member
Original poster
Mar 22, 2011
62
0
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 VB.net 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?
 

chown33

Moderator
Staff member
Aug 9, 2009
10,706
8,346
A sea of green
NSNumber is in a sense not object isn't it.
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.

Primitve types are "statically allocated" (even if that means in the heap). While object types are always on the heap.
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.


How do we know that a class can be statically allocated and what class cannot?
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:
http://developer.apple.com/library/...Foundation_DataTypes/Reference/reference.html

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.


Looks to me that NSNumber can be statically allocated where most other objects, like NSObject cannot right?
Wrong. NSNumber is a class. NSInteger is a typedef. Accuracy is important.


You really need to review the fundamental documentation.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
NSNumber is in a sense not object isn't it....

Looks to me that NSNumber can be statically allocated where most other objects, like NSObject cannot right?

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.
 

Sydde

macrumors 68030
Aug 17, 2009
2,552
7,050
IOKWARDI
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?
 

admanimal

macrumors 68040
Apr 22, 2005
3,531
2
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.