Re: Newbie Memory Questions on a Code Fragment
Re: Newbie Memory Questions on a Code Fragment
- Subject: Re: Newbie Memory Questions on a Code Fragment
- From: mmalc Crawford <email@hidden>
- Date: Wed, 21 Jan 2009 09:04:34 -0800
On Jan 21, 2009, at 7:07 AM, Kenneth Bruno II wrote:
On Jan 21, 2009, at 9:23 AM, James Cicenia wrote:
First of all, you probably should just use the localized list of
month names that you can get through NSDateFormatter:
NSDateFormatter *aFormatter = [NSDateFormatter new];
NSArray *listOfMonthNames = [[aFormatter standaloneMonthSymbols]
retain];
This will give you an NSArray populated with NSString objects that
contain the localized month names in the proper order. Notice that
I retained the NSArray object. I did this because it is given to me
autoreleased so if I want to own it I need to retain it.
As has been stated so many times here, talking in terms of whether
something is autoreleased or not is typically counter-productive. It
may or may not be autoreleased. You don't care. All you care about
is whether you own it or not.
The very simple rules for memory management are given here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html#
>
To diagnose memory management problems, you can use the Clang/LLVM
static analyser which will tell you about problems even before you run
your application:
<http://clang.llvm.org/StaticAnalysis.html>
When I no longer need it I'll just call release on the object, this
would most likely be done in the dealloc method of the class in
which I initialized my object.
As a general statement, this is at best misleading.
If you maintain an object as an instance variable, you're expected to
provide accessor methods to retain and release it as well.
The objecForKey method returns an autoreleased NSArray.
"An array you don't own".
You should only call release on objects that you have created
through methods that begin with alloc, new, or copy or objects that
you have previously called retain upon. I suggest that you review
the Cocoa Memory Management Rules to understand this further:
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
>
If you review that, you will find that your summary contains a small
but important omission. This is why it's typically better simply to
point to the Guide than to try to summarise yourself.
NSDateFormatter *aFormatter = [NSDateFormatter new];
NSArray *listOfMonthNames = [[aFormatter standaloneMonthSymbols]
retain];
One small error here, I should have added this line after these two
in order to properly release the NSDateFormatter:
[aFormatter release];
This needs to be done because I created a new NSDateFormatter which
has a retain count of 1.
"Which you don't own..."
Chasing retain counts is one of the surest ways of quickly becoming
confused when trying to track down memory management problems.
Since I don't need it past this point I should release it. It's a
small memory leak if I don't but it's a good idea to always properly
clean up after yourself.
It's not clear why this is simply a "good idea"? You should not allow
your program to leak memory. Even a "small" memory leak on an iPhone
application can become a terminal problem if the code is called often
enough.
Instead of adding an additional line to release I could have also
just changed the first line to this:
NSDateFormatter *aFormatter = [[NSDateFormatter new] autorelease];
The advantage to using autorelease is that I now don't need to
remember to release later and it puts the allocation and cleanup all
in one line, producing cleaner code. The disadvantage is that
autoreleasing takes up a bit more time and memory than just
releasing the object. In this case that's negligible, only worry
about it if you are creating and autoreleasing tons of objects in
time or memory-critical code.
Best practice is to avoid autorelease where you can.
On iPhone, this is especially true. You should get into the habit of
always directly managing objects' lifetimes when you can.
mmalc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden