mikeash.com pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html#commentsmikeash.com Recent CommentsThu, 28 Mar 2024 14:25:02 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssDhruvil Vyas - 2016-01-11 00:28:28http://www.mikeash.com/?page=pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html#commentsCan you update this code to be ARC-complaint ? cf0e9143d4b0289dfd5bc0dc1a3fa0ffMon, 11 Jan 2016 00:28:28 GMTmikeash - 2012-05-05 01:31:05http://www.mikeash.com/?page=pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html#commentsI think you're right that this is a potential danger, although not a realistic one when using the default @synthesize implementation. I never quite realized that problem with the setter pattern you show, but it makes me glad that I've always written mine to do the retain first: <br /><code> <br />[newValue retain]; <br />[_var release]; <br />_var = newValue; <br /></code> <br />It also makes me glad that ARC saves us from having to worry about stuff like that.42ad21990b8002e585e49ff1a806efbfSat, 05 May 2012 01:31:05 GMTPeter N Lewis - 2012-05-04 09:24:41http://www.mikeash.com/?page=pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html#commentsI believe there is a risk with this line: <br /> <br /><code>[previousBucket setNext: [bucket next]];</code> <br /> <br />if the setter is written in certain legitimate ways, eg as shown in <a href="http://cocoadev.com/wiki/AccessorMethods">http://cocoadev.com/wiki/AccessorMethods</a>: <br /> <br /><code> <br />&nbsp;&nbsp;&nbsp;if (newValue != _var) { <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[_var release]; <br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_var = [newValue retain]; <br />&nbsp;&nbsp;&nbsp;} <br /></code> <br /> <br />If the setter releases its _next variable before retaining the input parameter, then since [bucket next] has not retained it, it will be a dangling pointer. <br /> <br />In this case you're probably safe since the setter is synthesized and Apple's code will be appropriately defensive, but still it's worth either pointing out the danger or defending against it with your own retain/release, or implementing your own setter with defined safe semantics. <br />c48ef92d156e8aceb506688fc796b8ecFri, 04 May 2012 09:24:41 GMTJordy/Jediknil - 2012-03-16 18:31:03http://www.mikeash.com/?page=pyblog/friday-qa-2012-03-16-lets-build-nsmutabledictionary.html#commentsEnjoyed reading these as usual. One editorial note: <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">However, <code>return 0;</code> is a perfectly valid hash function, just slow. In Cocoa, the <code>hash</code> method on <code>NSObject</code> provides this hash function.</div></div> <br /> <br />My initial reading of this was that NSObject's hash function <i>was</i> <code>return 0;</code>. Maybe it'd be clearer if you mentioned something about the object's address?4f8c0e62c4298ae51200697f4421286bFri, 16 Mar 2012 18:31:03 GMT