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.
Related
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.
#interface Foo : NSObject
{
extern int gGlobalVar;
int i;
}
-(void)setgGlobalVar:(int)val;
#end
#implementation Foo
-(void)setgGlobalVar:(int)val
{
i = 5;
NSLog(#"i = %i", i);
gGlobalVar = val;
}
#end
I can declare i in interface and use it in implementation without any errors. But I cannot declare a variable of the type extern in interface. Why is this so? Why do I get an error which says that: "Type name does not allow storage class to be specified"?
Short Description:
The bracketed section of a class's #interface OR #implementation is only for declaring instance variables (aka "ivar"). The extern keyword is only for use with global variable declarations (or functions, but that's another topic.)
Therefore, you cannot declare an extern ivar.
Gritty Details:
Variables are first declared, and then defined. This distinction is typically blurred for variables in local scopes, as a locally declared variable without an explicit definition will often be allocated and given a default value by the compiler.
Global variables are potentially available in any scope, provided that scope knows the global exists. That's where the keyword extern comes in -- it declares that the global variable exists, and was defined elsewhere. This is only useful when you want to access a global variable in different code files.
Best Practices: Your book has some code that declares an extern variable in an implementation file (e.g. ".m" files, etc.)... that can work, but it's a bad practice because you're making potentially bad assumptions about whether that global actually has a valid definition elsewhere. (But, fancy compilers will discover this type of error.)
Instead, the best practice is to declare an extern variable once in a header file, have an accompanying implementation file that's dedicated to defining the externs in that header, and then include that header in other implementation files that want to use that global variable.
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.
i have a global variable in 1 of the class like
classA.h
const NSString *global;
classA.m
global=[array objectAtIndex:0];//a array store sort of string
and in another class i want to call this global variable
classB.m
import "class.h"
NSLog(#"%#",global);
but it doesnt work,i know when i jus assigned a value directly to my global variable instead of from another variable it will work but can somebody show me how to make it achieve from a array?
In the header, use:
extern const NSString *global;
and in the implementation (.m):
const NSString *global;
The "extern" reference tells all including files that the variable exists, but it's declared elsewhere. Finally, in your implementation file, you put the actual declaration.
You cannot do this like that.
const NSString *global;
NSString const *global;
both mean a pointer (that can be changed) to a constant NSString object. In Objective-C constant objects make no sense. The compiler cannot enforce the constness of objects. It can not know wether a method changes the internal state of an object or not. Also all the classes in the library always take pointers to non-constant objects as parameters for their methods, so having any const object pointers will cause a lot of warnings.
On the other hand there are constant pointers to objects which are declared like this:
NSString * const global;
This means the pointer points to a regular NSString object, but it’s value cannot be changed. This means that you also have to initialize the value of the pointer (it cannot be changed later). This is used to define constants. But this only works with NSStrings and string literals. For all other classes there is no way to specify a compile-time constant object thats required for the initialization. And in this case it is a true constant - string literals are immutable by definition.
But in your case you can do away with the const. You want to change the pointer later so it cannot be a NSString * const. If you insist on a global you’d just have to make it a regular NSString *. On the other hand - globals are evil. You should change your design so you don’t need it.