dealloc

I use code like the following (inside my appController.m for example) to do some cleanup when my application terminates... - (void) dealloc { [myObject release]; // myObject 's dealloc will not be called either !!! [arraySMSs release]; [super dealloc]; } This method never get called when the app quits! Why ? Is there a better place to do my clean up ? The fact that is not called addresses memory-leak issues ? Or the OS does take care of clean up ? Thank you... There is no reason for the system to ensure that every object is individually deallocated upon application termination. Doing so is

I know declared property generates accessor method which is someway just syntax sugar. I found quite a lot people use self.property = nil in their dealloc method. 1) In Apple's Memory Management document, p23 It says: The only places you shouldn’t use accessor methods to set an instance variable are in init methods and dealloc. why shouldn't? 2) In apple's Objective-C 2.0 , p74 Declared properties fundamentally take the place of accessor method declarations; when you synthesize a property, the compiler only creates any absent accessor methods. There is no direct interaction with the dealloc

I've heard now from several sources (stackoverflow.com, cocoa-dev, the documentation, blogs, etc) that it is "wrong" to use accessors and settings (foo, setFoo:) in your init and dealloc methods. I understand that there is there is a remote possibility of confusing other objects that are observing the property if you do so. (a simple example is given here ) However, I have to say that I don't agree with this practice for the following reason: The new Objective-C runtime (the one on the iPhone and the 64-bit runtime in 10.5) allows you to declare properties without declaring a corresponding

int main(){ Employee *e = new Employee(); delete e; delete e; ... delete e; return 0; } e 's not a reference, it's a pointer. You get undefined behaviour if you try to delete an object through a pointer more that once. This means that pretty much anything can happen from 'appearing to work' to 'crashing' or something completely random. It's undefined behavior, so anything can happen. What's likely to happen is bad. Typically, the free store is a carefully managed system of free and allocated blocks, and new and delete do bookkeeping to keep everything in a consistent state. If you delete again

Is it a bad idea to use the dot notation to initialize retain properties to nil in my init methods? With any ordinary property like this: @property (nonatomic, retain) id foo; Say in my init method I set self.foo = nil . The synthesized method first releases or autoreleases foo (not exactly sure of the underlying impementation). Is foo guaranted to be nil before the first setter or getter call? Or would it point to random garbage unless I explicitly set foo = nil without the dot notation? Is it a bad idea to use the dot notation to initialize retain properties to nil in my init methods? Yes,