mikeash.com pyblog/the-how-and-why-of-cocoa-initializers.html commentshttp://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsmikeash.com Recent CommentsThu, 28 Mar 2024 16:13:02 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssLogan Cautrell - 2009-04-11 02:53:33http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsI think I see my confusion now. In the case of getting self back from super and then having a problem initializing you are responsible for releasing the half baked instance. <br /> <br />I'm trying to make the transition to Cocoa full time. While I feel like I have a good understanding of retain/release cycles, I am struggling to understand proper initialization routines. This article and discuss have made this much more clear to me. <br /> <br />Thanks!8cbafff9e0a694545ee4fc45efdbde3cSat, 11 Apr 2009 02:53:33 GMTmikeash - 2009-04-11 00:53:54http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#comments<i>If</i> you return nil on error, then you must release self, otherwise the object will leak.902dababcf098a088171596f300a59ccSat, 11 Apr 2009 00:53:54 GMTLogan Cautrell - 2009-04-10 23:58:27http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsI was looking at the following Apple doc page. <br /> <br /><a href="http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/FrameworkImpl.html">http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/FrameworkImpl.html</a> <br /> <br />In it the example code indicates that in case of an error self should be released. What is going on here? <br /> <br />I don't believe most of the ntializers I've seen have ever done this.5e0089b23611d73a6803a0def59effdfFri, 10 Apr 2009 23:58:27 GMTmikeash - 2009-03-21 09:31:17http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsYes, any time you write 'someivar' in code, it gets implicitly translated to 'self-&gt;someivar'. Reassigning to the self pointer will redirect all ivar accesses. <br />c67a4e6229c7e35572d7c05c57396349Sat, 21 Mar 2009 09:31:17 GMTBjoern Knafla - 2009-03-21 02:44:05http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsThanks for this great post that explains many of my irritations with Obj-C initialization methods. <br /> <br />Though one question remains and I couldn't find an answer in Apple's documentation (though I might have overseen it): <br /> <br />Are all accesses to ivars implicitly channeled through self? <br /> <br />Otherwise assigning a new instance to self by way of self = [super init] would result in subsequent access to ivars of an instance that shouldn't exist anymore. <br /> <br />Cheers, <br />Bjoernf16fcb3e5870ec8b9afe8e5a8da5ab8aSat, 21 Mar 2009 02:44:05 GMTBlacktiger - 2008-10-16 01:04:09http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsJD, I think you are correct. Tthe superclass should send a [self autorelease] message before passing the new instance on. The code in your example might horribly fail by trying to assign newself to self after self is deallocated.3aeb39f6fa1554ba4a9c039888ad56feThu, 16 Oct 2008 01:04:09 GMTDrew McCormack - 2008-10-15 03:49:36http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#comments <br />One case where I often return a new instance is when I want to load a configured instance from a nib inside the init method. Happens quite often.361ff5fc762e69c1731460b96b267cf3Wed, 15 Oct 2008 03:49:36 GMTmikeash - 2008-10-12 23:37:40http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsI'm pretty sure that the link to NSManagedObject is evidence for every single one of those facts. Indeed, looking through them, "NSManagedObject does it" is proof of every single one of them. What do you want beyond that? <br /> <br />As for your question, standard memory management rules apply. Within any given scope, the sum of alloc/copy/retain should match the sum of release/autorelease. That means your example would be wrong, because you have an unbalanced release. And the superclass -init would have an unbalanced alloc, copy, or retain. So, yes, if the superclass -init creates a new object to return then it is necessarily responsible for releasing the old one.e5070089cd53152fe488e6d7a1a6d04dSun, 12 Oct 2008 23:37:40 GMTJean-Denis - 2008-10-12 17:06:40http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsGreat post. However, il would be even greater if you added evidence to each of your "fact" statements, however trivial that evidence might be. Your link to NSManagedObject is definitely evidence. <br /> <br />Finally, there is still another unclear point: when [super init] returns *another* instance, what happened to the original instance? Who is responsible for releasing it? I have seen people doing things such as: <br /> <br />newself = [super init]; <br />if (newself != self) { <br />&nbsp;&nbsp;[self release]; <br />&nbsp;&nbsp;self = newself <br />} <br />if (self) { <br />&nbsp;... <br />} <br />return self; <br /> <br />Which I believe is wrong, as I think that releasing self is the superclass's responsibility *if* it returns a new instance. <br /> <br />Am I correct? <br /> <br />JD68c40035e48c5a124811efc3a56201beSun, 12 Oct 2008 17:06:40 GMTJames Bucanek - 2008-10-11 23:42:20http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsHere's another reason to stick to the Apple init pattern: Performance. <br /> <br />The code <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">if ([super init]!=nil) ...</div></div> <br /> <br />actually produces 5 <b>more</b> machine instructions than <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">if ( (self=[super init])!=nil ) ...</div></div> <br /> <br />(Xcode 3.1, gcc 4.0.1, Intel, standard Release build optimization settings) <br /> <br />I have no idea if this is a special gcc optimization that recognizes and optimizes the standard init pattern or not, but reassigning self in the init method actually produces less (and presumably faster) code than trying to omit it. <br /> <br />How's that for win-win?b8abb4efecfd37fe8a9bcb43acfabab0Sat, 11 Oct 2008 23:42:20 GMTLee - 2008-10-11 20:46:16http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsI had read a lot of the different discussions on this topic and yours has convinced me to use the "Apple Way". I stand corrected.fbd1063383f8dc2ebadd721eb66bf220Sat, 11 Oct 2008 20:46:16 GMTAhruman - 2008-10-10 16:40:08http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsHere I thought this would be related to the recent discussion on objc-language about how to gracefully fail in init. :-)1398efed1d9745c969c7375bb82ecd29Fri, 10 Oct 2008 16:40:08 GMTAnonymous Custard - 2008-10-10 11:02:26http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsOh no you didn't just lay smack down on the Shipley?061aa7c14c28c6721e979a710168263aFri, 10 Oct 2008 11:02:26 GMTTim Buchheim - 2008-10-10 08:24:06http://www.mikeash.com/?page=pyblog/the-how-and-why-of-cocoa-initializers.html#commentsvery nice summary. :-) <br />302f03e4ec30abb9ef92d3b174451561Fri, 10 Oct 2008 08:24:06 GMT