Why should a self-implemented getter retain and autorelease the returned object
2013-06-10 23:09
531 查看
-(id)getMyInstance {return myInstanceVar ;}
or
-(id)getMyInstance {return[[myInstanceVar retain] autorelease];}
What's the difference ? The second one allows the caller to get an instance variable of a container object, dispose of the container and continue to play with the instance variable until the next release of the current autoreleased pool, without being hurt by the release of the instance variable indirectly generated by the release of its container:
aLocalVar =[aContainer getAnInstanceVar];[aContainer release]; doSomething(aLocalVar);
If the "get" is implemented in the first form, you should write:
aLocalVar =[[aContainer getAnInstanceVar] retain];[aContainer release]; doSomething(aLocalVar);[aLovalVar release];
The first form is a little bit more efficent in term of code execution speed. However, if you are writing frameworks to be used by others, maybe the second version should be recommanded: it makes life a little bit easier to people using your framework: they don't have to think too much about what they are doing…;) If you choose the first style version, state it clearly in your documentation… Whatever way you will be choosing, remember that changing from version 1 to version 2 is save for client code, when going back from version 2 to version 1 will break existing client code…
Compare this code
return[[title retain] release];// releases immediately
with this
return[[title retain] autorelease];// releases at end of current run loop (or if autorelease pool is drained earlier)
The second one guarantees that a client will have a non-dealloced object to work with.
This can be useful in a situation like this (client code):
NSString*thing =[obj title];[obj setTitle:nil];// here you could hit retainCount 0!NSLog(@"Length %d",[thing length]);// here thing might be dealloced already!
The retain (and use of
autoreleaseinstead of
release) in your
titlemethod prevents this code from blowing up. The autoreleased object will not have its
releasemethod called until AFTER the current call stack is done executing (end of the current run loop). This gives all client code in the call stack a chance to use this object without worrying about it getting dealloc'ed.
The Important Thing To Remember: This ain't Java, Ruby or PHP. Just because you have a reference to an object in yer [sic] variable does NOT ensure that you won't get it dealloc'ed from under you. You have to retain it, but then you'd have to remember to release it. Autorelease lets you avoid this. You should always use autorelease unless you're dealing with properties or loops with many iterations (and probably not even then unless a problem occurs).
相关文章推荐
- 09 - 删除vtkDataObject中的ShouldIReleaseData() and ReleaseDataFlag 方法 VTK 6.0 迁移
- The Biggest Changes in C++11 (and Why You Should Care)
- object-c的Retain and Release(保留与释放)
- The Biggest Changes in C++11 (and Why You Should Care)
- c# dynamic,maybe I should say it is just some shortcut for "Object", box and unbox, without the cast
- object-c的Retain and Release(保留与释放)
- BAYESIAN STATISTICS AND CLINICAL TRIAL CONCLUSIONS: WHY THE OPTIMSE STUDY SHOULD BE CONSIDERED POSITIVE(转)
- The Biggest Changes in C++11 (and Why You Should Care)
- CCObject(m_uReference(被引用次数) m_uAutoReleaseCount(加入释放池次数) release retain acceptVisitor)
- Object-C内存管理---资源自动释放池(The Autorelease Pool)
- object-c的Retain and Release(保留与释放)
- The Biggest Changes in C++11 (and Why You Should Care)
- [转]The Biggest Changes in C++11 (and Why You Should Care)
- Should the government pay the money to build the musem and theater, why?
- Objective-C and retain/release of returned objects
- The Biggest Changes in C++11 (and Why You Should Care)(C++11语言标准主要变化)
- The Biggest Changes in C++11 (and Why You Should Care)
- The Biggest Changes in C++11 (and Why You Should Care)
- C++11的变化-The Biggest Changes in C++11 (and Why You Should Care)
- Why we should overwrite the hashCode() when we overwrite the equals()