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 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.
Stack memory allocation is considered safer as compared to heap memory allocation because the data stored can only be access by owner thread. Memory allocation and de-allocation is faster as compared to Heap-memory allocation.
Whenever an object is created, it's always stored in the Heap space and stack memory contains the reference to it. Stack memory only contains local primitive variables and reference variables to objects in heap space.
The Heap Space contains all objects are created, but Stack contains any reference to those objects. Objects stored in the Heap can be accessed throughout the application. Primitive local variables are only accessed the Stack Memory blocks that contain their methods.
The heap is a memory used by programming languages to store global variables. By default, all global variable are stored in heap memory space. It supports Dynamic memory allocation. The heap is not managed automatically for you and is not as tightly managed by the CPU.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With