Does the order of statements in the dealloc method matter? Does the [super dealloc] need to be at the top of the method? Does it matter?
Also in e.g. viewDidLoad. Should [super viewDidLoad] be at the top of the method?
It ABSOLUTELY matters.
What you do depends on whether you're using Automatic Reference Counting (ARC) or manual reference counting.
Using Manual Release-Retain
Manual Release-Retain (MRR) is default memory management for all versions of Mac OS X, and the only way to handle memory until Xcode 4.2.
With MRR, [super dealloc] should be at the end of your method.
So your code should look like this:
- (void)dealloc
{
[member release];
[super dealloc];
}
The super dealloc actually frees the memory. Think about that. If you access an instance variable after that, like this:
[super dealloc];
[member release];
...it means that the instance variable is potentially invalid. Between the call to super dealloc and the call to member release, theoretically the bytes that stores the member pointer could have been changed to something else!
As Apple explains it in the Memory Management Programming Guide:
The role of the dealloc method is to free the object's own memory, and dispose of any resources it holds, including ownership of any object instance variables.
You do this by disposing of any resources your object holds, and calling [super dealloc]. Which disposes any objects it holds, and calls its super. And so on, and so on, until eventually the root object marks the memory used by the instance itself as free. By the time [super dealloc] returns, your instance has been freed. (Of course, the pointers in it are probably valid, but that's an implementation detail you shouldn't rely on.)
Generally, when constructing (or loading) let the super do the work first. When tearing things down, do your work first.
See also:
dealloc, NSObject Class Reference, Mac OS X Developer Library
Deallocating an Object, Object Ownership and Disposal, Memory Management Programming Guide, Mac OS X Developer Library
With Automatic Reference Counting
Automatic Reference Counting (ARC) is the new way of doing memory management introduced in Xcode 4.2. With ARC, the compiler adds memory management code when compiling your application. It has some wrinkles you'll want to read more about before using it (mostly, limited compatibility with older OS versions).
With ARC, you don't (and can't) call [super dealloc] at all. Instead, [super dealloc] is called when your dealloc finishes.
See also:
LLVM Automatic Reference Counting dealloc
Does the order of statements in the dealloc method matter? Does the [super dealloc] need to be at the top of the method? Does it matter?
It should go at the end. The idea is to say "I've torn down all the bits I've done, so now I'll let my parent class do the same" (recursively)
Also in e.g. viewDidLoad. Should [super viewDidLoad] be at the top of the method?
It should go at the top. The parent class should do what it needs to do to load its view before the subclass loads its parts, because it might rely on something the parent class needs to set up first.
Related
I am new to iphone and I want to know when does -(void) dealloc method call. I know it is used to release objects but can we release any kind of object using dealloc method? And is it necessry to add this method and why we write [suped dealloc] in dealooc method?
share your views.
Here is the explanation straight from APPLE's Docs
The NSObject class defines a method, dealloc, that is invoked
automatically when an object has no owners and its memory is
reclaimed—in Cocoa terminology it is “freed” or “deallocated.”.
Important
Never invoke another object’s dealloc method directly.
Here is the answer why we call [super dealloc]?
You must invoke the superclass’s implementation at the end of your
implementation. You should not tie management of system resources to
object lifetimes
When an application terminates, objects may not be sent a dealloc
message. Because the process’s memory is automatically cleared on
exit, it is more efficient simply to allow the operating system to
clean up resources than to invoke all the memory management methods.
You Can release object those which is allocted, copy, or retain by you this is simple to understand. You can not release object those are not allocating by you means autorelease object, which ios detect for no more use in memory ,that time autorelease pool drain that time those object released from memory automatically.
And object dealloc method called when object retain count becomes zero.
You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0). See Memory Management Programming Guide for more details on the use of these methods.
Subclasses must implement their own versions of dealloc to allow the release of any additional memory consumed by the object—such as dynamically allocated storage for data or object instance variables owned by the deallocated object. After performing the class-specific deallocation, the subclass method should incorporate superclass versions of dealloc through a message to super:
Refer this Link
This is really weird in my perspective. I've never seen anything like it. I put all my releases in a method called releaseMethod. Then in my dealloc and didReceiveMemoryWarning, I have [self releaseMethod]; I do this to be more object orienteted and save code because I have a lot of releases. But, occasionally (2 out of 5 times, give or take), I get EXC_BAD_ACCESS on the releaseMethod call in dealloc. The code is below. I didn't know it was possible to have a method call get bad access. I understand memory management and there is no memory involved in calling a method, right?
Thanks in advance.
- (void)dealloc {
[super dealloc];
[self releaseMethod];
}
Put your [super dealloc] at the end of the dealloc so you can first cleanup things in your class before cleaning up things in the superclass (which you might depend on).
If you send the message release to an object that has already been deallocated, this is the message you will get. Check that you aren't overreleasing something in releaseMethod. Remember, when an object is deallocated, it will release objects that it is retaining.
You should also put [self releaseMethod] before you call [super dealloc].
I am a former java programmer, and I am having some troubles managing the memory on cocoa touch.
In fact, I think I got the retain/release trick, but still I am not sure I got it right.
For example, I am creating and adding a subview to the main window:
aViewController=[[AViewController alloc]init];//aViewController is (nonatimic,assign), so retaincount = 1 after this line?
[self.window addsubview aViewController];
[aViewController release];//retaincount=0?
And in aViewController I have an IBAction:
[self.view removeFromSuperView];
How can I be sure the object aViewController gets completely 'deleted' and memory released after I removed it from superview (think that controller as a graphic-heavy view controller)?
Also, generally, is there a way to be sure an object is deallocated? I am aware that if I ask ownership of an object I have to release it at a certain point, but what if I just want the object's pointer to be null at a certain point(not basing on the retaincount)? Should I call dealloc directly? I find sometimes very confusing to keep under control the retain/release mechanism.
If someone could give me a quick breakdown to make my mind 'click', i would be extremely grateful.
Thanks.
The short answer is you shouldn't worry about when an object gets deallocated (unless you are debugging a memory management problem). You should just worry about ensuring that if your code retains, copies or inits an object, it releases or autoreleases it. By doing so you will ensure reference counts are properly maintained and hence deallocation will be managed for you.
Leave the task of deciding when to dealloc an object to the runtime. Never call dealloc directly unless you are calling the super classes dealloc method at the end of your objects dealloc method.
Also, don't even look at the retain count property of an object. Various pieces of the framework manipulate those too during the lifetime of the object, and you'll see that number move around seemingly at random. It'll just drive you nuts.
The really important thing is to make sure you've got the objects retained that would be a problem if they went away suddenly, and released when you're okay with them going away suddenly.
aViewController=[[AViewController alloc]init];retainCount is 1
[self.window addsubview aViewController.view];retainCount is 2 (adding the view increments the retainCount)
[aViewController release];retain count decrements to 1;
[aViewController removeFromSuperView];retain count decrements to 0;
Now the dealloc method will be called the allocated memory will be freed. This is what have understood please correct me if i am wrong i always find difficulties during memory management.
I am finishing up an iPad application, and for me, that means filling in all of the dealloc methods in my classes.
I have many views in my nib and most of them contain subviews (i.e. UIViews, UILabels, etc.). Should I release the child views before releasing the parent? If the parent view is released, will its child views be released, as well?
Sample:
-(void)dealloc
{
[super dealloc];
[childView release]; // Do I need this if I use the next line?
[parentView release]; // Will this perform the line above?
}
Both childView and parentView are properties of my view controller. Both have been retained.
Anything that you have retained (whether explicitly or through a retained property) needs to be released for the memory management to be balanced.
Also, you should invoke [super dealloc] at the end of your dealloc implementation, not the beginning (for instance, because you might depend on superclass resources still being available at the time).
By the way, saving your dealloc-writing until you're finishing up work on the app is a backwards way to go. I know it seems like house-cleaning work, but the fact is until you're managing memory properly, you're going to have a very skewed view of how your app really performs.
Ideally you should write your dealloc calls as you write your #synthesize statements. In other words, you add a property to your class, you set it up as a retained property, you write its #synthesize and -release code. That way you know your memory management is basically clean (I mean, at the class property level anyway) and you can code with confidence.
Since you specified that you have subviews from a NIB, it sounds like you also may need to pay close attention to the viewDidUnload method.
Any views which are automatically allocated from the nib you can implicitly release by setting the outlet to nil. For example:
- (void)viewDidUnload {
[super viewDidUnload];
self.subviewOutletOne = nil;
self.subviewOutletTwo = nil;
}
Then for any objects which you explicitly retain, you release them in the dealloc method like you are planning to do:
- (void)dealloc {
[myDataArray release];
[coolAnimatedImage release];
[myCustomSubview release];
[super dealloc];
}
Also be sure to check out the LEAKS instrument. This is a random tutorial for using the built in leak analysis tool. There may be others / better ones. It can a pain to get up and running the first time but is completely worth it.
I found that the iphone have viewDidUnload, and dealloc. I want to release the object. Which method should I use to release the object? What's the different between them?
Send release or autorelease to release an object. You shouldn't send dealloc; the Obj-C runtime will do that.
If you're asking where you should release an owned object, read: "When should I release objects in -(void)viewDidUnload rather than in -dealloc?"
Do not call dealloc. Use the retain-release model for memory management, and Objective-C will take care of deallocating memory for you.
See this link for a good explanation of how retain-release works.
The difference is that viewDidUnload is used to release "spare" objects in low memory situations while dealloc is used to release all objects when the view is no longer needed.
This means that you will almost always have a dealloc method but have a viewDidUnload method only where it makes sense.