how are these NSMutableArray initializations different? - iphone

In a branch of my code, I previously used this
NSMutableArray *array1 = [[NSMutableArray alloc] init];
The above array is used populate a UITableVew.
Just cause, I switched to the following:
NSMutableArray *array1 = [NSMutableArray arrayWithCapacity:0]
I made no other changes to my code) and my app crashes whenever I try to scroll down the list in the UITableView.
It looks like my array is not initialized correctly. Can someone explain why this would happen? Are the two methods not identical wrt how the underlying memory space is allocated?

Your second line of code is not retaining the NSArray, which is causing a crash. You'll need to call [array1 retain] after you call arrayWithCapacity:.
There's quite a bit of useful information in this post: Understanding reference counting with Cocoa / Objective C
In general, if you're calling a class method that doesn't start with "new" or "init" (e.g. arrayWithCapacity), you can usually assume that the returned object will be autoreleased.

Related

Understanding memory management in ios

I am in the process of learnig objective-c and programming an iPad app. One thing I keep tripping myself up on and having to re-read is memory management. I am getting there...slowly. Basic rules such as for every alloc / retain you must have a release is useful. However, one relatively basic thing eludes me and I wonder if someone could explain...
Take the following code...
NSArray *myArray = [[NSArray alloc] init];
myArray = [someNSSet allObjects];
This is relatively straight forward coding and would require a [myArray release] statement.
However, I keep seeing examples of (and indeed, I have used extensively the following 'short cut'...
NSArray *myArray = (NSArray *)[someNSSet allObjects];
How, as far as I understand when you use the (NSString *) you dont need to use a [myArray release] statement, but I dont understand why.
Could someone possible explain?
NSArray *myArray = [[NSArray alloc] init];
myArray = [someNSSet allObjects];
this code is leaking myArray because you lose the reference to NSArray that you've allocated on the first line; you don't need to alloc here, because on the second line you're assigning a new value to myArray.
NSArray *myArray = (NSArray *)[someNSSet allObjects];
and this code example is perfectly fine, you're assigning the result of [someNSSet allObjects] to myArray pointer and you don't own the returned value, so you don't need to care about releasing it.
Consider using ARC (Automatic Retain Counting) for you project. With ARC the compiler takes care of retain counts so you don't have to, in fact aren't allowed to. There is a refactoring that will convert a current project.
As you said, there is a leak in the first code you posted. so you must add a release:
NSArray *myArray = [[NSArray alloc] init];
[myArray release];
myArray = [someNSSet allObjects];
In fact, when you obtain an object through a method that starts with alloc, new or copy, you own it, and you should release it. That's why, here you should release the array you obtained using the method alloc. This convention makes it easy to know when you own objects and when you don't. So remember: alloc, new or copy.
As for the second example, you obtained the array though a method that doesn't start with one of the three words (alloc, new or copy), so you don't own the object, and you are not responsible of releasing it. In fact, the array you obtained is an autoreleased object, which means that even though its retain count is currently 1, it will be automatically released when something called the autorelease pool is drained.
Here is a reference about Memory Management Rules.
In the first line:
NSArray *myArray = [[NSArray alloc] init]
some amount of memory is allocated for an array (actually in this case it is senseless since the size of the array is 0. Keep in mind that NSArray is immutable!).
The variable myArray holds the address of the first byte of the reserved memory area.
Now in the second line you change the value of myArray which now will point to the first byte of the memory area where [someNSSet allObjects] is stored. At this moment you do not know any more where the array is stored what you've created in the first line. And so you have a leak.
The line:
NSArray *myArray = (NSArray *)[someNSSet allObjects];
is correct, since you do not reserve any memory at this point. If you are not using ARC you might call retain in order to keep GC away from the referenced block of memory. In other way you might receive a BAD_EXEC when the owner of the object releases it and you try to access it through e.g.: [myArray objectAtIndex:0]

NSMutableArray initWithCapacity method description and memory management

It's about the instance method of NSMutableArray "initWithCapacity".
From documentation, the Return Value is described as:
Return Value
An array initialized with enough memory to hold numItems objects.
The returned object might be different than the original receiver.
There seems to be a typo at "different than", my guess is it should be "different from". And also if the returned object is indeed different from the original, do we have to worry about releasing the memory associated with the original object ?
Hope that somebody knowledgable on this can help ...
http://developer.apple.com/library/mac/#documentation/cocoa/reference/foundation/Classes/NSMutableArray_Class/Reference/Reference.html#//apple_ref/occ/cl/NSMutableArray
You have created an object with alloc, and you are responsible for the memory of that object. The fact that initWithCapacity: may return a different chunk of memory than what originally came from the call to alloc does not change that.
Initializer methods in Cocoa are allowed to deallocate the instance they are passed and create a new one to be returned. In this case, it's necessary for initWithCapacity: to do so, since you're actually asking it to reserve more memory that alloc didn't know about and couldn't have allocated.
This is the reason that alloc and init... should always be paired: [[NSMutableArray alloc] initWithCapacity:10]
Regarding initWithCapacity: specifically, bbum (who knows of what he speaks -- Apple engineer) says that it's usually unecessary. It does not preclude you from expanding the array past the specified size. All it does is potentially allow the array to do some initial optimization*; unless you've measured and it makes a significant difference, it's probably not necessary.
*See Objective-c NSArray init versus initWithCapacity:0
Any time you use a method that contains the word alloc then you are responsible for releasing the memory. For example if you did the following
NSMutableArray *myArray = [[NSMutableArray alloc] initWithCapacity:10];
//Store data into the array here
//Once done you need to release the array
[myArray release];
--Editied post because I meant to type alloc and used init instead.

iPhone memory management, a newbie question

I've seen in (Apple) sample code two types of ways of allocation memory, and am not sure I understand the difference and resulting behavior.
// FAILS
NSMutableArray *anArray = [NSMutableArray array];
[anArray release];
// WORKS
NSMutableArray *anArray1 = [[NSMutableArray alloc] init];
[anArray release];
By "FAILS" I mean I get crashes/runtime warnings etc., and not always as soon as I call the release...
Any explanation appreciated.
Thanks
Please keep in mind that
NSMutableArray *anArray = [NSMutableArray array];
acts like:
NSMutableArray *anArray1 = [[[NSMutableArray alloc] init] autorelease];
So doing a release again will cause the crash as you are trying to release an autoreleased object.
Hope this helps you.
Thanks,
Madhup
In the first instance you are getting an autoreleased object, which you don't need to release
The second instance is where you are manually allocating the memory yourself, so you a responsible for releasing it.
Read this documentation for help:-
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
To clarify on djhworlds response:
alloc, copy, mutableCopy and new make you the owner of the new object, retain makes you an owner of an existing object, and you become responsible for -[(auto)release]ing it. Other methods return an object that has been -[autoreleased], and thus you don't have any responsibility for it, but beware: It will disappear on the next iteration of the run loop (usually), as that is generally when the autorelease pool drains.
The practical upshot of this is that the //FAILS version works perfectly in the context of that particular piece of code, but once the run loop rolls around and the pool is drained, your object, being already released and gone, causes things to go boom.

Objective C release, autorelease, and data types

I'm new to memory managed code but I get the idea pretty well.
On taking my app through the leaks tool in XCode, I noticed I only had to clean up my custom objects, but not dynamically created arrays for example, so I figured those data types are autoreleased - makes sense since I only had to release the arrays I used as properties that had a (retain) on them.
Then I noticed something peculiar : I was getting a leak on a certain array initialized like this :
NSMutableArray *removals = [NSMutableArray new];
but not a similar one
NSMutableArray *removals = [NSMutableArray arrayWithCapacity:9];
Now, the reason one was set up with "new" is that it could have 0-99 items in it, whereas the other one I knew was going to always be 9. Since both arrays are passed to the same method later based on user interaction, I was either getting a leak if I did not release at the end of the method, or an exception if I did!
I changed the first array to
NSMutableArray *removals = [NSMutableArray arrayWithCapacity:99];
and I get no leaks and don't have to release anything. Can anyone explain?
As noted in the memory management rules, whenever you have an object that you have created with +alloc, +new, -copy, or -mutableCopy, you own it and are responsible for releasing it at some point. (In fact, +new is just shorthand for [[MyClass alloc] init].) As you noted, creating an array via [NSArray new] without releasing it is a memory leak. However, if you handle this object properly, it is usually possible to release it at some point. For example:
If the method that uses the array is called from within the method that creates the array, then you should be able to release the array after it has been used. If the inner method needs to keep a more permanent reference to the array around, then that method is responsible for sending -retain and, eventually, -release to the object. For example:
- (void)myMethod {
NSArray *removals = [NSArray new];
// ...
[someObject someOtherMethod:removals];
[removals release];
}
If you created the array in an -init method for an object, then the -dealloc method can release it when the object is destroyed.
If you need to create the array and then return it from the method, you've discovered the reason that autoreleasing was invented. The caller of your method isn't responsible for releasing the object, since it isn't an +alloc, +new, -copy, or -mutableCopy method, but you need to ensure it is released eventually. In this case, you manually call -autorelease on the object before you return it. For example:
- (NSArray *)myMethod {
NSArray *removals = [NSArray new];
// ...
return [removals autorelease];
}
When you create the array via +arrayWithCapacity:, you aren't calling one of the "special" methods, so you do not have to release the result. This is probably implemented with -autorelease, much like the last example above, but not necessarily. (Incidentally, you can also create an empty autoreleased NSMutableArray with [NSMutableArray array]; the method is found in NSArray, so it won't show up in the documentation under NSMutableArray, but it will create a mutable array when sent to the NSMutableArray class.) If you're going to be returning the array from your method, you can use this as shorthand for [[[NSMutableArray alloc] init] autorelease]—but it is just a shortcut. In many situations, though, you can create an object with -init or +new and manually release it at the appropriate time.
This is how things implemented behind the scene:
+(NSMutableArray*) new
{
return [[NSMutableArray alloc] init];
}
and
+(NSMutableArray*) arrayWithCapacity:(NSNumber)capacity
{
return [[NSMutableArray alloc] initWithCapacity:capacity] **autorelease**];
}
In first case the array is allocated only and you're responsible for de-allocating it. In contrary the arrayWithCapacity has autoreleased for you and won't cause leak even you forget to deallocate.
Cocoa uses certain naming conventions. Anything that starts with alloc, new, or copy returns something with a retainCount of 1 and you are required to release. Anything else that a function returns has a balanced retainCount (it might be held by something else, or it might be retained and out released).
So:
NSMutableArray *removals = [NSMutableArray new];
Has a retainCount of 1, and:
NSMutableArray *removals = [NSMutableArray arrayWithCapacity:99];
or
NSMutableArray *removals = [NSMutableArray array];
Don't since the methods are not prefixed with alloc, new or copy. This is all spelled out in the memory management documentation. In particular:
You take ownership of an object if you
create it using a method whose name
begins with “alloc” or “new” or
contains “copy” (for example, alloc,
newObject, or mutableCopy), or if you
send it a retain message. You are
responsible for relinquishing
ownership of objects you own using
release or autorelease. Any other time
you receive an object, you must not
release it.

Why might an array decoded from plist or JSON not respond to :class or :count while a programmatically created array does?

I'm encountering an extremely vexing problem. I have a UITableViewController which in its init method decodes a dictionary from a JSON or plist file (I've tried both), then retrieves an array from that dictionary. Later on, in the method tableView:numberOfRowsInSection:, I'm returning the count of that array.
However, for reasons beyond me, calling count on the array at that point crashes the application, though calling count directly after assignment in init doesn't. Also, if I replace the initial assignment with a programmatically created array (via NSArray initWithObjects), it works fine.
JSON decoding in init:
NSString *jsonPath = [[NSBundle mainBundle] pathForResource:#"Categories" ofType:#"json"];
SBJSON *jsonParser = [SBJSON new];
NSDictionary* dict = [jsonParser objectWithString:[NSString stringWithContentsOfFile:jsonPath encoding:NSUTF8StringEncoding error:nil]];
categories = [dict objectForKey:#"ContentCategories"];
// Outputs correct count
NSLog(#"Count: %#", [NSNumber numberWithInt:[categories count]]);
Programmatic init:
categories = [[NSArray alloc] initWithObjects: [[NSDictionary alloc] initWithObjectsAndKeys:#"Junk", #"Title"]];
// Outputs correct count
NSLog(#"Count: %#", [NSNumber numberWithInt:[categories count]]);
UITableViewController number of rows method:
// Outputs correctly if programmatically created, crashes if decoded from JSON/plist
NSLog(#"Count: %#", [NSNumber numberWithInt:[categories count]]);
I've tried the "categories" variable as an ivar, a propertied-ivar, and as a class variable, with no luck.
Thanks for your help!
I'm not familiar with that JSON parser, but if it's following Cocoa conventions, objectWithString will be returning an autoreleased object. This means, it will be deallocated on the next iteration through the runloop, unless you retain it. When Cocoa collection classes deallocate, they release each object they contained, so categories will also get released. This is why it works at first, but not later in the program.
The reason it works by making it a property, is that the synthesized setter created retains categories (assuming you set your property with the retain parameter, which I assume you did), so it won't get released. That is the proper solution, nice work. :) Calling retain on categories would also have worked.
The Cocoa convention is that if a method name contains "alloc" or "copy", or begins with "new", the object returned has a retain count of 1, and you are responsible for releasing it. Otherwise, the returned object has a retain count of zero (it has been autoreleased), and will be deallocated on the next iteration through the runloop, unless you retain it (in which case you take responsibility for releasing it later).
I recommend reading this:
Memory Management Programming Guide for Cocoa
Edit:
The reason it worked using [[NSArray alloc] initWithObjects...] is, because that method contains "alloc", the returned array has not been autoreleased, and so is still around later when you access it.
Note: changing "categories" to a property and adding "self." in front of all of the setting/getting methods (e.g., self.categories = ...) made this work. For some reason, calling just "categories" was returning an object of type UIWindow in the numberOfRows method (!). That seems incredibly odd to me (I would hope I would just encounter compiler errors), but then again, I'm relatively new to obj-c.