What is the difference between the code below?
#implementation MyClass
static int myVar =0;
int _myVar =0;
I am getting same values for different objects of MyClass and both are visible to the all methods of MyClass...
Static and global variable differ a lot in their behaviour to life and scope. First, let me distinguish between life and scope. Life of an object determines whether the object is still in the memory (of the process) whereas scope of the object is whether can I know the variable by its name at this position. It is possible that object is live, but not visible (not in scope) but not that object is not alive but in scope (except for dynamically allocated objects where you refer object through pointers).
Static variables are local in scope to their module in which they are defined, but life is throughout the program. Say for a static variable inside a function cannot be called from outside the function (because it's not in scope) but is alive and exists in memory. The next time this function is entered (within the same program) the same chunk of memory would be accessed now retaining the variables old value and no new memory is allocated this time for this variable like other variables in the function (automatic variables). So basically the variable persists throughout the program. Similarly if a static variable is defined in a global space (say at beginning of file) then this variable will be
accessible only in this file (file scope).
On the other hand global variables have to be defined globally, persists (life is) throughout the program, scope is also throughout the program. This means such variables can be accessed from any function, any file of the program.
So if you have a global variable and u r distributing ur files as a library and you want others to not access your global variable, you may make it static by just prefixing keyword static (of course if same variable is not required in other files of yours).
Neither of those variables are related to MyClass and both are global, which is why you are seeing the same value in all instances of MyClass. If you wanted to make _myVar an instance variable then it needs to go between brackets:
#implementation MyClass {
int _myVar;
}
...
#end
The difference between the variables in your code is that the static variable cannot be accessed outside the scope of the implementation file (which I assume is called MyClass.m), while the non-static one can be accessed from anywhere in the application, however you'd need to keep the compiler happy with an extern int _myVar; in any code that wants to access it; this is normally done by putting that extern declaration in a header file.
static limits the scope of your variable. In your case variable will be visible within MyClass file.
However, declaration of variable without static means that variable is automatic by default. It means that your static will live throughout all method calls and automatic will be allocated when you call a method and then at some point deallocated.
Related
These lines are both in the implementation file above the #implementation declaration.
NSString * const aVar = #"aVarStringValue";
static NSString *aVar = #"aVarStringValue";
As far as I understand, the second static is allocated once only within the lifetime of the application and this fact contributes to performance.
But does this mean it is essentially a memory leak seeing as that block of memory will never be released?
And does the first const declaration get allocated every time it is accessed in contrast?
static keyword in Objective-C (and C/C++) indicates the visibility of the variable. A static variable (not in a method) may only be accessed within that particular .m file. A static local variable on the other hand, gets allocated only once.
const on the other hand, indicates that the reference may not be modified and/or reassigned; and is orthogonal on how it can be created (compilers may optimize consts though).
It's worth mentioning that NSString literals get initialized and never get destroyed in the life of application. They are allocated in a read-only part of the memory.
The static only changes the scope of the variable, not how it is declared or stored.
In both cases, the compiler will create a constant version of the NSString instance that is stored in the mach-o file. Thus, there is only ever one instance of either (note that you can change the behavior to cause the string to be dynamically created on load of the mach-o, but there is still just one instance).
The static just marks the aVar variable as being visible within the scope of the compilation unit -- the file -- only. Without the static, you could redeclare the string as extern NSString *aVar; in a header somewhere and have access to it from anywhere.
The const is orthogonal and, in the case of of NSString reference is pretty much entirely irrelevant.
In order to resolve all possible discussions on need of static and position of const:
According to C99/GNU99 specification (which usually used for Objective-C code):
static
is storage-class specifier
objects of file level scope by default has external linkage
objects of file level scope with static specifier has internal linkage
const
is type-qualifier (is a part of type)
keyword applied to immediate left instance - i.e.
MyObj const * myVar; - unqualified pointer to const qualified object type
MyObj * const myVar; - const qualified pointer to unqualified object type
Leftmost usage - applied to the object type, not variable
const MyObj * myVar; - unqualified pointer to const qualified object type
THUS:
static NSString * const myVar; - constant pointer to immutable string with internal linkage.
Absence of the static keyword will make variable name global and might lead to name conflicts within the application.
int anInteger = 42;
void (^testBlock)(void) = ^{
NSLog(#"Integer is: %i", anInteger);
};
anInteger = 84;
testBlock();
Integer is: 42
This is an example from Apple official guide.
Now, for object value, it is easy to understand, it keeps a reference to it. So later on, when it's original reference changes to point to something else, or simply gets destroyed. This reference is still there, so reference count won't be zero, and the original value is kept.
But, for the example code above, it is not an object. The block keeps a reference to it, and then the value changes to 84. I suppose that is a change to itself instead of its copy, that means the value the pointer pointing to has changed. How can it still be 42?
From the Blocks and Variables section of the documentation:
The following rules apply to variables used within a block:
Global variables are accessible, including static variables that exist within the enclosing lexical scope.
Parameters passed to the block are accessible (just like parameters to a function).
Stack (non-static) variables local to the enclosing lexical scope are captured as const variables.
Their values are taken at the point of the block expression within the program. In nested blocks, the value is captured from the nearest enclosing scope.
Variables local to the enclosing lexical scope declared with the __block storage modifier are provided by reference and so are mutable.
Any changes are reflected in the enclosing lexical scope, including any other blocks defined within the same enclosing lexical scope. These are discussed in more detail in The __block Storage Type.
Local variables declared within the lexical scope of the block, which behave exactly like local variables in a function.
Each invocation of the block provides a new copy of that variable. These variables can in turn be used as const or by-reference variables in blocks enclosed within the block.
Rule 3 applies to the code in your question.
Blocks introduce the necessary indirection to make sure this happens. Variables that appear to be local but which are captured by blocks are actually allocated on the heap by the compiler. Among other things, this is necessary for that variable to be able to outlive the lifetime of the function it was declared in.
To make a long story short: Integral values are copied. (To be more precise: structs and object references are copied, too. But in the case of object references, it is a reference.)
BTW: This is the meaning of a closure. This is what closure are made for. The reason for their existence. You want exactly this behavior. Otherwise you would have to ensure, that a value is not changed while a block is running – maybe seconds or minutes later.
Are "local object variables" the variables that are used or initialized in a method, or are they the arguments taken in? I can't find this term in Xcode's documentation or Google.
I found this in the Objective-C book that I'm using. The full quote is
Local variables that are basic C data types have no default initial value, so you must set them to some value before using them. The three local variables in the reduce method are set to values before they are used, so that's not a problem here. Local object variables are initialized to nil by default. Unlike your instance variables (which retain their values through method calls), these local variables have no memory. Therefore, after the method returns, the values of these variables disappear. Every time a method is called, each local variable defined in that method is reinitialized to the value specified (if any) with the variable's declaration."
Based on your comment, I understand what the book means. Local variables are variables local to a particular scope (denoted by braces '{}' in C and Objective-C). Local variables are declared in the scope where they're used, as opposed to global variables which can be seen and used globally (to a file, multiple files or the whole program depending on declaration visibility). Instance variables are part of a class instance and can be used by any of its methods (and other classes too if declared using #public, though that's generally not good practice).
Primitive local variables are local variables whose type is a C primitive like int, float, char, etc. What the book is calling "local object variables" are simply local variables whose type is (a pointer to) an Objective-C object. Examples are NSString *, NSDictionary * and id.
Local variables are stored on the stack, as opposed to the heap. Variables on the stack go away at the end of the method or function call where they were declared. This Stack Overflow question has some good answers explaining the difference between the stack and the heap: What and where are the stack and heap?
The first result of a Google search for "local variables objective-c": http://blog.ablepear.com/2010/04/objective-c-tuesdays-local-variables.html .
Local variables are defined in the method and scope of the variables that have existed inside the method itself.
I frequently see a code snippet like this in class instance methods:
static NSString *myString = #"This is a string.";
I can't seem to figure out why this works. Is this simply the objc equivalent of a #define that's limited to the method's scope? I (think) I understand the static nature of the variable, but more specifically about NSStrings, why isn't it being alloc'd, init'd?
Thanks~
I think the question has two unrelated parts.
One is why isn't it being alloc'ed and init'ed. The answer is that when you write a Objective-C string literal of the #"foo" form, the Objective-C compiler will create an NSString instance for you.
The other question is what the static modifier does. It does the same that it does in a C function, ensuring that the myString variable is the same each time the method is used (even between different object instances).
A #define macro is something quite different: It's "programmatic cut and paste" of source code, executed before the code arrives at the compiler.
Just stumbled upon the very same static NSString declaration. I wondered how exactly this static magic works, so I read up a bit. I'm only gonna address the static part of your question.
According to K&R every variable in C has two basic attributes: type (e.g. float) and storage class (auto, register, static, extern, typedef).
The static storage class has two different effects depending on whether it's used:
inside of a block of code (e.g. inside of a function),
outside of all blocks (at the same level as a function).
A variable inside a block that doesn't have it's storage class declared is by default considered to be auto (i.e. it's local). It will get deleted as soon as the block exits. When you declare an automatic variable to be static it will keep it's value upon exit. That value will still be there when the block of code gets invoked again.
Global variables (declared at the same level as a function) are always static. Explicitly declaring a global variable (or a function) to be static limits its scope to just the single source code file. It won't be accessible from and it won't conflict with other source files. This is called internal linkage.
If you'd like to find out more then read up on internal and external linkage in C.
You don't see a call to alloc/init because the #"..." construct creates a constant string in memory (via the compiler).
In this context, static means that the variable cannot be accessed out of the file in which it is defined.
For the part of NSString alloc, init:
I think first, it can be thought as a convenience, but it is not equally the same for [[NSString alloc] init].
I found a useful link here. You can take a look at that
NSString and shortcuts
For the part of static and #define:
static instance in the class means you can access using any instance of the class. You can change the value of static. For the function, it means variable's value is preserved between function calls
#define is you put a macro constant to avoid magic number and string and define function macros. #define MAX_NUMBER 100. then you can use int a[MAX_MUMBER]. When the code is compiled, it will be copied and pasted to int a[100]
It's a special case init case for NSString which simply points the NSString pointer to an instance allocated and inited at startup (or maybe lazily, I'm not sure.) There is one one of these NSString instances created in this fashion for each unique #"" you use in your program.
Also I think this is true even if you don't use the static keyword. Furthermore I think all other NSStrings initialized with this string will point to the same instance (not a problem because they are immutable.)
It's not the same as a #define, because you actually have an NSString variable by creating the string with the = #"whatever" initialization. It seems more equivalent to c's const char* somestr = "blah blah blah".
These lines are both in the implementation file above the #implementation declaration.
NSString * const aVar = #"aVarStringValue";
static NSString *aVar = #"aVarStringValue";
As far as I understand, the second static is allocated once only within the lifetime of the application and this fact contributes to performance.
But does this mean it is essentially a memory leak seeing as that block of memory will never be released?
And does the first const declaration get allocated every time it is accessed in contrast?
static keyword in Objective-C (and C/C++) indicates the visibility of the variable. A static variable (not in a method) may only be accessed within that particular .m file. A static local variable on the other hand, gets allocated only once.
const on the other hand, indicates that the reference may not be modified and/or reassigned; and is orthogonal on how it can be created (compilers may optimize consts though).
It's worth mentioning that NSString literals get initialized and never get destroyed in the life of application. They are allocated in a read-only part of the memory.
The static only changes the scope of the variable, not how it is declared or stored.
In both cases, the compiler will create a constant version of the NSString instance that is stored in the mach-o file. Thus, there is only ever one instance of either (note that you can change the behavior to cause the string to be dynamically created on load of the mach-o, but there is still just one instance).
The static just marks the aVar variable as being visible within the scope of the compilation unit -- the file -- only. Without the static, you could redeclare the string as extern NSString *aVar; in a header somewhere and have access to it from anywhere.
The const is orthogonal and, in the case of of NSString reference is pretty much entirely irrelevant.
In order to resolve all possible discussions on need of static and position of const:
According to C99/GNU99 specification (which usually used for Objective-C code):
static
is storage-class specifier
objects of file level scope by default has external linkage
objects of file level scope with static specifier has internal linkage
const
is type-qualifier (is a part of type)
keyword applied to immediate left instance - i.e.
MyObj const * myVar; - unqualified pointer to const qualified object type
MyObj * const myVar; - const qualified pointer to unqualified object type
Leftmost usage - applied to the object type, not variable
const MyObj * myVar; - unqualified pointer to const qualified object type
THUS:
static NSString * const myVar; - constant pointer to immutable string with internal linkage.
Absence of the static keyword will make variable name global and might lead to name conflicts within the application.