Forums
New posts
Articles
Product Reviews
Policies
FAQ
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Menu
Log in
Register
Install the app
Install
Forums
macOS & iOS Developer Playground
macOS - Development and Darwin
Is implementing autorelease code in constructor a good idea ?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="wmprice1240" data-source="post: 924093" data-attributes="member: 99551"><p>Typically any well defined abstraction should not try and anticipate or make assumptions about the memory requirements for a particular client, platform, environment etc, and this includes the existence and scope of an autorelease pool. </p><p></p><p>At this point, your object has yet to be fully initialized so your essentially adding a partially initialized object to the autorelease pool which can have side effects. Similarly, Autorelease pools have a particular scope which is thread dependent. Embedding the autorelease knowledge into the initializer (note, the terms are different in Obj-C, there is no such thing as a 'constructor' in Obj-C) would make certain assumptions that might not be valid in all cases. </p><p></p><p>Obj-C has well defined semantics,idioms and usage patterns regarding object ownership and memory management. </p><p></p><p>You will want to read:</p><p></p><p><a href="http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html" target="_blank">Mac Dev Center: Memory Management Programming Guide for Cocoa: Introduction</a></p><p></p><p>If code clarity is your concern you may want to consider using the garbage collector that is now a part of Objective-C 2.0 if your platform (the iPhone does not support the GC) permits its use.</p></blockquote><p></p>
[QUOTE="wmprice1240, post: 924093, member: 99551"] Typically any well defined abstraction should not try and anticipate or make assumptions about the memory requirements for a particular client, platform, environment etc, and this includes the existence and scope of an autorelease pool. At this point, your object has yet to be fully initialized so your essentially adding a partially initialized object to the autorelease pool which can have side effects. Similarly, Autorelease pools have a particular scope which is thread dependent. Embedding the autorelease knowledge into the initializer (note, the terms are different in Obj-C, there is no such thing as a 'constructor' in Obj-C) would make certain assumptions that might not be valid in all cases. Obj-C has well defined semantics,idioms and usage patterns regarding object ownership and memory management. You will want to read: [url=http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html]Mac Dev Center: Memory Management Programming Guide for Cocoa: Introduction[/url] If code clarity is your concern you may want to consider using the garbage collector that is now a part of Objective-C 2.0 if your platform (the iPhone does not support the GC) permits its use. [/QUOTE]
Verification
Post reply
Forums
macOS & iOS Developer Playground
macOS - Development and Darwin
Is implementing autorelease code in constructor a good idea ?
Top