Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Apr 7, 2011, 10:24 PM   #1
teguh123
macrumors member
 
Join Date: Mar 2011
Static Field?

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
__________________
How to Learn Math
teguh123 is offline   0 Reply With Quote
Old Apr 7, 2011, 11:57 PM   #2
jiminaus
macrumors 65816
 
Join Date: Dec 2010
Location: 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* myObject;
jiminaus is offline   0 Reply With Quote
Old Apr 7, 2011, 11:57 PM   #3
chown33
macrumors 603
 
Join Date: Aug 2009
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.


Quote:
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".
chown33 is offline   0 Reply With Quote
Old Apr 8, 2011, 12:09 AM   #4
admanimal
macrumors 68040
 
Join Date: Apr 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.
admanimal is offline   0 Reply With Quote
Old Apr 8, 2011, 03:32 AM   #5
Sydde
macrumors 68000
 
Sydde's Avatar
 
Join Date: Aug 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.
__________________
You got to be a spirit. You can't be no ghost.
Sydde is offline   0 Reply With Quote
Old Apr 9, 2011, 12:35 PM   #6
teguh123
Thread Starter
macrumors member
 
Join Date: Mar 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 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?
__________________
How to Learn Math
teguh123 is offline   0 Reply With Quote
Old Apr 9, 2011, 01:35 PM   #7
chown33
macrumors 603
 
Join Date: Aug 2009
Quote:
Originally Posted by teguh123 View Post
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.

Quote:
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.


Quote:
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/m...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.


Quote:
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.
chown33 is offline   0 Reply With Quote
Old Apr 10, 2011, 01:18 AM   #8
admanimal
macrumors 68040
 
Join Date: Apr 2005
Quote:
Originally Posted by chown33 View Post
You really need to review the fundamental documentation.
And forget everything he knows about Visual Basic.
admanimal is offline   0 Reply With Quote
Old Apr 10, 2011, 02:41 AM   #9
firewood
macrumors 603
 
Join Date: Jul 2003
Location: Silicon Valley
Quote:
Originally Posted by teguh123 View Post
While object types are always on the heap.
Prehistoric Objective C implementations allowed creating objects on the stack, IIRC. The current Apple run-time does not.
firewood is offline   0 Reply With Quote
Old Apr 10, 2011, 08:12 AM   #10
gnasher729
In Time-Out
 
Join Date: Nov 2005
Quote:
Originally Posted by teguh123 View Post
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.
gnasher729 is offline   0 Reply With Quote
Old Apr 10, 2011, 01:11 PM   #11
Sydde
macrumors 68000
 
Sydde's Avatar
 
Join Date: Aug 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?
__________________
You got to be a spirit. You can't be no ghost.
Sydde is offline   0 Reply With Quote
Old Apr 10, 2011, 07:13 PM   #12
admanimal
macrumors 68040
 
Join Date: Apr 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.
admanimal is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
In the field for a new Mac chrisrosemusic1 iMac 9 Apr 28, 2014 10:48 PM
Field Test Mode macher iPhone 1 Jan 5, 2013 07:38 AM
Depth of Field Tutorial dipm06 Digital Photography 17 Dec 9, 2012 02:13 PM
Safari google search field next to URL field murraymint64 iPhone Tips, Help and Troubleshooting 0 Sep 3, 2012 05:32 PM

Forum Jump

All times are GMT -5. The time now is 01:43 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC