Question for the more curious

Hello,

I noticed in BMITime that if we comment out the last line: employees = nil; the employees still deallocate. So it seems that line has no effect. Is that correct?

So I thought the section Retain count rules might explain this behavior. It gives conventions for when using ARC. The NSMutableArray Employees is created in the main.m using alloc (and init). I thought that according to the first bullet point, then we have the responsibility to release the object. But it appears that we don’t have to. Does Employees not fall under the first bullet point or has the way ARC works changed?

Also, I am having difficulty understanding the second bullet point. First of all, what are a few examples of creating an object any other way? It says the retain count is one. So that is the same as in the first bullet point, but who owns it? I guess in particular I don’t understand when an object would not be put in the autorelease pool. It seems like they all do.

According to the link below, “You cannot explicitly invoke dealloc, or implement or invoke retain, release, retainCount, or autorelease.” But the third bullet point mentions “you” sending an object retain and the fourth bullet point mentions “you” sending an object release or autorelease if you no longer need it. I am not sure what to make of all of this. Can anybody elaborate on the third and fourth bullet points?

https://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html

There are several questions here, so I’ll take them one at a time.

  1. in simple command-line applications like this, that employees = nil line will seem like it’s not doing anything, as you say, because the objects still deallocate. The reason that they deallocate even with that line commented out, though, is that the program ends very shortly after that line anyway. In a bigger, more complex program (such as an iOS app), the program doesn’t end after doing a little work like this one does.

  2. I think that most of the remaining quetsions can be solved by re-examining the first few lines of this section, particularly, [quote] If you are using ARC, it is following these conventions behind the scenes.[/quote]. That is to say, this entire For The More Curious section is about non-ARC code. In an ARC-based project, you are not allowed to call retain, release, autorelease, or dealloc because the compiler does that work for you. In a non-ARC project, you are responsible for following the rules as laid out in this section.

  3. for the second bullet point, creating an NSDate object using [[NSDate alloc] init] is an example of creating it using alloc, meaning that you own the object and would need to call release on the object when you’re done with it. If you get an NSDate object using [NSDate date] however, since you did not use alloc/copy/new, you do not own the object and can assume it has been autoreleased.

All new projects have ARC turned on by default (which is a good thing!). It’s very rare to need to write non-ARC code these days, which is why all of this information has been pushed into a For the More Curious section at the back of the chapter. Generally, the only people writing non-ARC Objective-C code are maintaining very large, very old legacy code-bases (usually for large enterprise organizations with hundreds or thousands of developers, and thousands to millions of lines of Objective-C code to worry about). Companies often have difficulty upgrading their legacy codebases as the languages and tools evolve (for example, the introduction of ARC in 2011) due almost entirely to the massive burden that it would be, and so may still have lots of non-ARC code hanging around.

I hope all that helps some.

That does help. I considered that interpretation at one point. For some reason, the line “These are a set of memory management conventions that all Objective-C programmers follow” stood out and so I thought it applied to us as we use ARC. But now that I focus on the next sentence, I see what you were saying.

Thanks!