I've been working much more with Objective-C: The Big Nerd Ranch Guide than I have been with Programming in Objective-C (3rd edition) lately. I decided to pop back over to the PiO-C book to see how much the other book had already covered (and see if it didn't cover anything since PiO-C is supposed to be the more in-depth book) and I discovered something I should have noticed before.
At some point XCode started using either a different compiler (Clang/LLVM instead of GCC) or a different way of handling memory allocation called Automatic Reference Counting (ARC). A pretty big change happened in the default way new projects are created that really makes it tough to learn from older books (if August 2011 is considered old!).
What it comes down to for the newbie is basically this:
Old way new projects were generated:
New way new projects are generated:
This wouldn't be a super big deal except that the old way where you explicitly handle the NSAutoreleasePool isn't legit in newly generated projects. Going back and forth requires really mucking with the project settings to get it to not use ARC. If I was brand new at learning programming and decided to use Objective-C with XCode as a first language/environment it wouldn't take long to get exasperated. I'm already pretty irked that a new book I bought is obsolete!
I need to track down a step-by-step guide to editing the project settings to go back and forth from the old way and the new way in case I want to use any examples in the old book to learn something. If there was a way to tell it which to use at the start of the new project then that would be great.
I understand the benefit of the new way on a superficial level (just as superficial as I understood what the old way was doing). Coming from C I'm not afraid of doing my own memory management, but I get that it's something you don't want to mess with once you start working on larger frameworks. Even GDK/GTK did a lot of stuff for you (similar to "new" in C++).
For kicks I threw in a few malloc() and free() assignments inside and outside the @autoreleasepool block and I didn't get any complaints. That's a relief - I take very seriously the claim that you can always revert back to straight C and Obj-C is just a strict superset of features that doesn't change any of the known rules.
I just found a placeholder for the 4th edition (releases in a month or so) of PiO-C on Amazon that specifically mentions in the description coverage of XCode 4.2, ARC, and iOS 5. If TBNRG doesn't cover everything then I'll have to drop $30 on the latest edition of a book I already own. Well... that's the game isn't it?
Maybe in a few weeks I'll follow up this post with instructions on reverting to pre-ARC compiler options, but for now I'll stick with TBNRG.
One big disappointment is that although TBNRG or PiO-C goes into some depth about what NSAutoreleasePool or @autoreleasepool{} are really doing, I don't think it discusses much of when to use it. I've seen snippets of code that have multiple groups of @autoreleasepool{} blocks (and in the older book multiple NSAutoreleasePool allocations) but it's not super obvious when to use them. In comparison malloc() and free() look downright friendly.
It's horribly ironic. I started this journey as an almost spiteful motion to clear up my ignorance of pointers and memory. I got to a certain competence in C and now I'm hitting a roadblock with an entirely new flavor of memory management.
Maybe I should ditch XCode and do some AVR/PIC stuff.
No comments:
Post a Comment