This question already has answers here:
Releasing instances of NSNumber created with initWithInteger: vs. numberWithInt:
(3 answers)
Closed 9 years ago.
These are classes and they declares pointers... to objects right? You send methods to them like objects.
NSNumber * myNumber = [NSNumber numberWithInteger: x];
So why are they not released like so:
[myNumber release];
Thanks!
By convention, class method initializers like the one you've shown create autoreleased instances, so you don't need to call release unless you retain them somehow. However, the instance method initializers - like initWithInteger: in your case - return retained instances. Those you would need to release yourself.
There is a rule you should remember about memory management "NARC": When you use New Alloc Retain Copy you should release or autorelease object, otherwise you shouldn't.
Related
What are the pros and cons of creating an array (or any other collection using its respective factory method) with
[[NSArray alloc] init]
vs
[NSArray array]
in objective C? It seems like the latter factory method allows us to not worry about memory management, so I was curious if there's any point in ever using alloc + init, though I'm now more interested in all the differences between these two, and why one would choose one over the other.
Prior to ARC there was a critical difference. The alloc/init case returned a retained object, while the array case returned an autoreleased object.
With ARC the difference is less important. Probably the first case is a hair more efficient, but in most scenarios they are interchangeable.
In the first one, you have the ownership of array object & you have to release them.
NSMutableArray* p = [[NSMutableArray alloc] init];
[p release];
& last one you dont need to release as you don't have the ownership of array object.
NSMutableArray* p = [NSMutableArray]; //this is autoreleased
If you call release in this, then it will crash your application.
This question already has answers here:
Do I need to release a constant NSString?
(2 answers)
Closed 10 years ago.
In my research I've come across something peculiar.
#interface Class {
NSString *_string
}
- (void) Method1 {
_string = #"ASDF";
}
Intially I thought that _string was part of the autorelease pools and really didn't think about the memory aspect of it.
After reading this SO post Objective C NSString* property retain count oddity
I've realized that no, this is not the case, and that the retain count of _string is actually UINT_MAX
Obviously my thinking that _string was part of the autorelease pool was a fluke, and how I handled the variable just somehow worked out. What I would like to know, though, is: when does #"ASDF" get thrown away? I know I should be using properties and setters, but there is probably a lot of code out there that looks like this since assigning a constant to a variable is so intuitive.
What is the lifecycle of these immutable, literal NSStrings, and when will [_string length] actually return an error since #"ASDF" doesn't reside in memory anymore?
From Is a literal NSString autoreleased or does it need to be released?
Compiler allocated strings (of the format #"STRING") are constant, and
so -retain, -release, and -autorelease messages to them are ignored.
You don't have to release or autorelease foo in this case (but it
won't hurt).
Under the hood when you do
NSString* yourString = #"ABC";
the string will be stored in a area of memory called data segment. This area never changes after the application is launched. Here strings are treated as constants for your app. At the same time a string is an object, so if you want to keep it you call retain or copy.
On the contary when you do
NSString* yourString = // alloc-init
you create an object on the heap. If you forget to release you have a memory leak. If someone else destroy it, and you try to access it, you have a bad access to that memory location.
Hope that helps.
An immutable string (NSString) that is created manually follows the normal reference counting rules and thus life cycle.
In your example, the string is even more special because it is actually a string literal. As is the case for any literal, they reside in special memory and only get destroyed when the executable terminates.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Use of alloc init instead of new (Objective-C)
Does any of you use +new of the NSObject to alloc & init the object?
Lets say i got an object C derived from Object B which all are from NSObject. To create an instance of Object C
C newInstanceOfC = [C new]; // This will call the alloc & init of class C.
is this any better than
C newInstanceOfC = [C alloc] init];
other than less things to type. What is good practice?
cheers
Arun
alloc] init] is best practice. In particular, objects have different ways to init, including zero, one or more than one parameter. Using new makes an automatic selection of init, but having init visible can help you troubleshoot some nasty bugs that can happen if you initialise a UI element but forget to set the frame, etc.. You'll get compiler warnings about the use of the init method in some circumstances too.
They are both exactly the same, new is the new way, as that wasn't possible before, but use the one that you like the most.
I usually use new since it is shorter, although in several cases you can't since you usually want to do something like:
[[myObject] alloc] initWith...];
Sorry for the newbie question, but I need a NSMutableArray with some NSNumber inside, created dynamically in a for cycle. My code looks like this:
for (...){
NSNumber *temp_number = [[NSNumber alloc] initWithInteger:someNSInteger];
[target_array addObject:[temp_number copy]];
[temp_number release];
}
Is this a correct way to do it? Does it leak?
Thanks! Miguel
Yep, that leaks. You want:
NSNumber *temp_number = [[NSNumber alloc] initWithInteger:someNSInteger];
[target_array addObject:temp_number];
[temp_number release];
So, no copy. The logic is that because you use alloc, you end up owning temp_number. You then add it to the array and the array does whatever it needs to. You've used temp_number for its intended purpose, so you no longer want to own it and release it.
If you were to take a copy, that would create another instance of NSNumber, which you also own, and therefore which you should also release when you're finished with.
In practice, the array (if it's allocated and exists, rather than being nil), will retain the object for itself, but that's an implementation detail specific to that class and not something you should depend upon or even be particularly interested in beyond the contract that says that the objects you add can later be found in the array.
eventPoints = [[NSMutableArray array] retain];
What does the "retain" keyword do along with the "array"?. "array" is not defined anywhere.
Also eventPoints was declared as a NSMutableArray.
I am just trying to learn. Thanks
Check out this question I asked: iPhone memory management (with specific examples/questions)
It took me a while to get a hang of this too. Hope this helps!
EDIT: As for what [NSMutableArray array] does, according to the docs on NSArray, it does this: "Creates and returns an empty array." and is used by mutable subclasses of NSArray, such as NSMutableArray. Basically, it's the same as doing: [[[NSMutableArray alloc] init] autorelease] (or something really similar). Because it's autoreleased, you need to call retain on it to keep the variable.
1) What does the "retain" keyword do along with the "array"?
As you know, objective-C uses referencing counting for memory management. "retain" increments 1 by everyPoints.
2) "array" is not defined anywhere.
"array" is defined in NSArray. NSMutableArray is a subclass of NSArray, so NSMutableArray can use functions defined in NSArray. "array" is a class method that creates and returns an empty array.
There are four ways to explicitly increment 1 in objective-c: alloc, copy, retain, attain
Because you create an empty array without using any of these, you manually increment 1 by "retain". So in the future, you might need to [everyPoints release] to decrement 1 to deallocate it.