PDA

View Full Version : [SOLVED]Can someone confirm that I have the right idea? (Memory management question).




chrono1081
Feb 6, 2012, 11:18 PM
Hi guys,

I know ARC exists but I'd rather work on learning manual memory management on iOS and just have a question:

I have this method:

-(void)foundLocation:(CLLocation *)loc
{
CLLocationCoordinate2D coord = [loc coordinate];

//Create date string
NSDate *currentDate = [NSDate date];
NSString *date = [NSDateFormatter localizedStringFromDate:currentDate
dateStyle:NSDateFormatterShortStyle
timeStyle:NSDateFormatterShortStyle];

//Create an instance of MapPoint with the current data
MapPoint *mp = [[MapPoint alloc] initWithCoordinate:coord
title:[locationTitleField text]
subtitle:date];

//Add it to the map view
[worldView addAnnotation:mp];

//MKMapview retains its annotations, we can release
[mp release];

//Zoom the region to this location
MKCoordinateRegion region = MKCoordinateRegionMakeWithDistance(coord, 250, 250);
[worldView setRegion:region animated:YES];

[locationTitleField setText:@""];
[activityIndicator stopAnimating];
[locationTitleField setHidden:NO];
[locationManager stopUpdatingLocation];
}

I am I correct for NOT releasing the objects in bold? My understanding is that since they are convenience methods (I hope thats the correct terminology) that they are not to be released and that the class takes care of that for me since they were not created using alloc, or init.

I just want to reaffirm my understanding of this.



WestonHarvey1
Feb 6, 2012, 11:35 PM
You are correct. You do not release currentDate because it was initialized and added to the autorelease pool by Date. You don't own that object so if you want to hang on to it you need to retain it:

NSDate *currentDate = [[NSDate date] retain];

Then you'd release it.

chown33
Feb 6, 2012, 11:38 PM
If you understand the principle of object ownership, you'll be able to answer the question yourself.

Read the section "Memory Management Policy", sub-heading "Basic Memory Management Rules".
https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html

The rules are quite simple, and their use is extremely uniform. So uniform, in fact, that you have to look long and hard to find something from Apple that doesn't follow the rules.

To answer your question is a straightforward task of logically applying the rules, which are very clearly stated. So take the code you showed, systematically apply the rules, and post the answer you get.

Once you have an answer, study the rules. In particular, make sure you understand the principle of ownership, and how all the rules (including ones about convenience methods) flow from that basic principle.

For what it's worth, ARC works by following the same rules, also in a systematic way, so once you know the principle and the rules, you'll understand how ARC is able to do what it does.

chrono1081
Feb 6, 2012, 11:43 PM
You are correct. You do not release currentDate because it was initialized and added to the autorelease pool by Date. You don't own that object so if you want to hang on to it you need to retain it:

NSDate *currentDate = [[NSDate date] retain];

Then you'd release it.

If you understand the principle of object ownership, you'll be able to answer the question yourself.

Read the section "Memory Management Policy", sub-heading "Basic Memory Management Rules".
https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html


The rules are quite simple, and their use is extremely uniform. So uniform, in fact, that you have to look long and hard to find something from Apple that doesn't follow the rules.

To answer your question is a straightforward task of logically applying the rules, which are very clearly stated. So take the code you showed, systematically apply the rules, and post the answer you get.

Once you have an answer, study the rules. In particular, make sure you understand the principle of ownership, and how all the rules (including ones about convenience methods) flow from that basic principle.

For what it's worth, ARC works by following the same rules, also in a systematic way, so once you know the principle and the rules, you'll understand how ARC is able to do what it does.

Thats guys for both of your responses :)

I do have the list of rules printed and set near my computer and knew they adhered but I just wanted to make 100% positive I was correct and there wasn't some strange exception somewhere.

Also I had one more question. The following code runs fine but I never see anything created this way. Is this valid? Or is there an issue this code creates that I am unaware of: (Its the same code as above, the change is bolded)


//Create date string
NSString *date = [NSDateFormatter localizedStringFromDate: [NSDate date]
dateStyle:NSDateFormatterShortStyle
timeStyle:NSDateFormatterShortStyle];


I could be wrong but I thought I remembered something stating not to use convenience methods like this.

WestonHarvey1
Feb 6, 2012, 11:55 PM
Also I had one more question. The following code runs fine but I never see anything created this way. Is this valid? Or is there an issue this code creates that I am unaware of: (Its the same code as above, the change is bolded)


//Create date string
NSString *date = [NSDateFormatter localizedStringFromDate: [NSDate date]
dateStyle:NSDateFormatterShortStyle
timeStyle:NSDateFormatterShortStyle];


I could be wrong but I thought I remembered something stating not to use convenience methods like this.

Hmm. That works fine for me, creates the correct date string. Have you looked at it in the debugger right after the invocation? Is it nil or something?

chrono1081
Feb 7, 2012, 12:00 AM
Hmm. That works fine for me, creates the correct date string. Have you looked at it in the debugger right after the invocation? Is it nil or something?

Nope it has a value. Everything looks valid and it runs fine, but I never see people nest a convenience method like this.

Then again most of my learning is out of books so maybe thats why.

WestonHarvey1
Feb 7, 2012, 12:05 AM
Nope it has a value. Everything looks valid and it runs fine, but I never see people nest a convenience method like this.

Then again most of my learning is out of books so maybe thats why.

I personally see nothing wrong with the practice. It will be autoreleased just the same, and you save a line of code getting the pointer reference you won't be using again.

Readability can be impacted when you start chaining a whole bunch of calls like that into one line, so it's really style preference more than anything else.

chrono1081
Feb 7, 2012, 12:07 AM
I personally see nothing wrong with the practice. It will be autoreleased just the same, and you save a line of code getting the pointer reference you won't be using again.

Readability can be impacted when you start chaining a whole bunch of calls like that into one line, so it's really style preference more than anything else.

I thought it would get autoreleased the same but I wasn't sure. Thanks so much for the clarification :)

chown33
Feb 7, 2012, 12:14 AM
Then again most of my learning is out of books so maybe thats why.

Sometimes the coding style in books is dictated by what fits on one line of a printed page. Or because there is a need to refer to individual lines of code in the accompanying text, such as a paragraph that says "Line 2 does xxx. Line 3 does yyy." Or to keep some rather longish expression or message-send from being split by a page break.

And sometimes code is originally written with short statements, rather than deeply nested expressions, because debugging the former is easier (especially if complicated clauses and parentheses (sometimes nested) end up being necessary (perhaps due to operator precedence)).