Note to self on overriding dealloc in Obj-C

I went through the chapter in Obj-C:TBNRG about ARC and retain cycles and got to the end with my head spinning. I understand what's going on but following which instances of what class own who is dizzying. The Objective-C style of having two files per class (one header file one implementation file) makes it hard to follow since you can't see everything at once. Well... maybe having everything in one big file isn't the way to go either.

Anyways, I intend on going through it again for good measure.

Something that had been bothering me is that in the classes you make for the example you override the dealloc method so that you can toss a print statement in to say when it's being deallocated (in an effort to show what actions on the data cause it to deallocate automatically). I realized that the implication would be that the data isn't actually getting deallocated! So, to the internets I go and I find that The Big Nerd Ranch has a forum for its books, wherein I find this:

http://forums.bignerdranch.com/viewtopic.php?f=151&t=3223

Basically: the magic of ARC saves you by somehow knowing to call the dealloc of the parent class (or the parent's parent class which inherits NSObject I think in the example). I don't like magic, but I'll roll with it for now.

The trouble for newbs with Objective-C, Cocoa, and XCode

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.

Back on the horse

I'm getting through some more of the Big Nerd Ranch Objective-C book today. It took the free time of the Thanksgiving holiday and some gentle prodding from my wife to do it (she preferes that I indulge my more productive hobbies rather than play Skyrim all day).

It's been a while so I'm having to play catch-up. A quick note to self about Objective-C class organization:

Class header file:

Class implementation (.m) file:

main.m:

The new Blogger interface doesn't take well to the Pastebin inserts. I'm working on it.

so far so good

This is part of an "apply what you know" part of the Objective-C Programming:TBNRG book. It's supposed to help solidify using object methods (and reading the Apple documentation on string methods I guess).

Instance methods and class methods

I have a somewhat decent grasp of common OOP terms like class, method, inheritance, polymorphism, etc. Something that I keep seeing in my casual reading about Objective-C is that some methods in class definitions have + preceding them, and others -.

The + means the method is a class method, and the - means it's an instance method. An example in the book I'm reading today (Objective-C Programming: The Big Nerd Ranch Guide) illustrated one difference between the two.

The NSDate class has a method called date which returns a pointer to an instance of the NSDate class.

NSDate *sometime = [NSDate date];

date is a class method.

There is another method called timeIntervalSince1970 which returns a double (seconds since 1970). This is an instance variable, so you call it on the instance.

double timepassed = [sometime timeIntervalSince1970];

It's not legit to say:

double timepassed = [NSDate timeIntervalSince1970];

and you'll get warned that no such class method exists.

So there's OOP with Objective-C lesson one. There are class methods and instance methods. I tried doing a few different things, like:

NSDate *now = [NSDate];

but I got an error "Expected identifier". Is an identifier a class method that has to be run? Is this the concept as a constructor in C++? I peeked into NSDate.h and found a few other class methods alongside date. I found an instance method called init and thought I should try it too

NSDate *now = [NSDate init];

and this didn't give me an error. So that's confusing - both init and timeIntervalSince1970 are instance methods but the former works and the latter fails. Going back to NSdate.h I found that timeIntervalSince1970 isn't quite in the same place as init is, so maybe it has different rules. Further confusing the matter is that init is of type id which is a generic pointer to an Obj-C object, and timeIntervalSince1970 is a double.

Well shoot. I mean this post to be about how I learned something and now I'm just more confused.