4 ms·
UIPopoverController does not retain itself and will cause a crash shortly after that release. Both the iOS SDK and the Cocoa SDK are fairly inconsistent about w
by rbritton 16y ago
UIPopoverController does not retain itself and will cause a crash shortly after that release. Both the iOS SDK and the Cocoa SDK are fairly inconsistent about which presentation classes require retaining and which handle that themselves -- UIAlertView does not require it, for example.
- seanalltogether 16y agoPrecisely, and that's the thing I've come to learn about objective-c memory management. It's fairly easy to learn as the article points out, but in practice when you have to interface with other developers code, it can be a confusing mess.
- andolanra 16y agoI know this from practice, having come in halfway through a project on iOS whose code was exquisitely, terrifyingly awful. I was fine on memory management; it was hunting down previous memory management errors that took up most of my time. I ended up giving up and reimplementing certain classes because it was seriously simpler than debugging the existing code. I think the issue is that trivial examples—for example, the kind you have in a blog post or comment—will invariably look simple and easy. In a non-trivial application, "four basic rules" ends up being four more things that can create bugs.
- vannevar 16y agoAnd this brings up a point overlooked in the article: it isn't about the time it takes to do things right, it's also about the time it takes to track down the problem when you inevitably (you ARE human after all) make a mistake. To me, that's the real value of GC, because memory allocation errors are tedious and time consuming to debug. The author is confusing 'habitual' with 'easy', and the two concepts are very distinct. And even beyond that he undervalues the debug time saved with automated GC.