I have 2 new questions:
1) Consider this line:
NSString *myString = [[NSString alloc] initWithString: @"Value"];
There were two things I learned, but I would like confirmation:
As I learned, the "alloc" message indicates that the instance of NSString will be stored in the "heap" memory.
I understood also that primitive variables such as "chars" are stored in the "stack" memory.
Does this mean that:
- the instance of NSString is stored in the heap memory;
- AND that this object has an iVar pointer (when the initWithString method was called) to the "Value" string of primitive "chars", which reside in the stack memory?
How does this work in actuality?
The second question is directly related and causes for me a personal dilemma (probably because I'm missing a point):
2) Which of the two approaches would you consult and why?:
NSString *myString = [[NSString alloc] initWithString: @"Value"];
NSString *myString = @"Value";
If my first question is confirmed, both approaches should "in the end" point to chars that are stored in the stack memory. I therefore don't actually see the purpose of using the first option and being bothered with the retain count.
Short answer: In this case, both lines have the same result It's fine to assign the string constant directly to myString.
Longer answer:
It's true that Objective-C objects are allocated on the heap. It's not true, though, that "primitive" values are always stored on the stack. Local variables are stored on the stack, whether they're primitive or not. (You can, for example, declare a local variable that's a struct, which isn't considered primitive.) You can store primitive values on the heap, but the only way to access them in that case is via a pointer. For example:
int *someInt = malloc(sizeof(int)); // allocate a block of memory to hold an int
*someInt = 42; // store data in that memory
The reason that we always use pointers to refer to Objective-C objects is that objects are always allocated on the heap. If you want to store something on the stack, the compiler needs to know its size. In Objective-C, the size of an object isn't known until the program is actually running.
So, back to your strings. Try executing the following two lines:
NSString *foo = [[NSString alloc] initWithString:@"foo"];
NSString *bar = @"foo";
If you break after the second line, you'll find that foo and bar contain the same address; that is, they point to the same object. Because NSString objects are immutable, creating one with a constant string just returns a pointer to that constant.
Why is there even an -initWithString: in NSString if that's all it does? NSString is a "class cluster," which is to say that NSString is the public interface to several different internal classes. If you pass a NSString* that's not a constant into -initWithString:, the object you get back might be an instance of a different class than what you get when you use the constant. As a class cluster, NSString hides a lot of implementation details from you so that you get good performance for different types of strings without having to worry about how it all works.
NSStrings are interesting because they were until recently the only type of Objective-C object that could be provided as a literal. The block objects added in iOS 4 and OS X 10.6 are the other recent addition that I'm aware of, but they have their own particular rules so I mention that just for completeness.
C primitives can be stored on the heap or on the stack. For example:
- (void)someMethod
{
int i = 3; // i is on the stack
}
- (void)someOtherMethod
{
int *i = (int *)malloc(sizeof(int)); // i now points to an 'int' on the heap
}
Most Objective-C objects can be stored on the heap only. You're quite right to say that alloc furnishes a new copy of an object on the heap, and the result of your myString call will be to have a pointer to an NSString on the heap.
However, the @"" syntax is shorthand for creating an object. @"Value" actually creates an object literal. So, for example, you could do:
NSLog(@"%@", [@"Value" substringFromIndex:1]);
And the output would be 'alue'. You can send the substringFromIndex: message to @"Value" because it's a literal object.
Exactly what NSString does with initWithString: is an implementation specific but you can be certain that it will take a copy of the thing pointed to if it needs to. Otherwise you'd see odd behaviour if you did something like this:
NSMutableString *mutableString = [NSMutableString stringWithString:@"String"];
NSString *immutableString = [NSString stringWithString:mutableString];
[mutableString appendString:@" + hat"];
// immutableString would now have mutated if it was simply
// keeping a reference to the string passed in
You therefore needn't worry about the lifetime of anything you pass to it. It's NSString's job to deal with that.
In practice, NSString object literals never actually expire so the point is a little moot. If however you'd used initWithUTF8String: or something else that takes a C literal, and that C literal was on the stack, you'd still have nothing to worry about because NSString would deal with it.
In answer to your second question, I'd favour the second version on the grounds that it's shorter and therefore more clearly demonstrates what you intend to do. There are some theoretical performance benefits to the latter — especially if you use the same literal in multiple places — but they're so incredibly negligible as not to be worth considering nowadays.
