Question

I’m transitioning to ARC (Automatic Reference Counting) and this document was very helpful: Transitioning to ARC Release Notes. It says:

How do blocks work in ARC?

Blocks “just work” when you pass blocks up the stack in ARC mode, such as in a return. You don’t have to call Block Copy any more. You still need to use [^{} copy] when passing “down” the stack into arrayWithObjects: and other methods that do a retain.

Can somebody elaborate on this a little bit or give some example? I understood that to mean usually I don’t need to do [block copy] anymore even if the block is used outside the declared scope as ARC now will take care of it more smartly, but I still need to copy it when I want to pass the block to functions that would retain it. Is this correct?

Actually I’ve experimented with it a little bit and so far it seems okay even if I pass blocks to arrays without copying, so the question. Thanks!

Answer 1

Let’s consider the problem from an MRC (manual reference counting) perspective. When you are returning a stack block from a function, it is always the right thing to do to return a copy of it (usually with [[ copy] autorelease]). This is because the lifetime of the stack block is that function call, which is ending. So in order for the returned pointer to point to a valid block after returning, of course you have to return a heap copy.

However, what about for passing a block as an argument to a function or method. Should you pass a copy of it? It’s a little more complicated. We know that, if you need to store a block for later use in a place that will outlive the function call (e.g. in an instance variable or global variable, etc.), you need to store a copy of the block. But how do we know when this is true (and if it is true, which function (caller/callee) is responsible for copying it)?

Generally, when you pass it to a function or method whose parameter is of block type, then you don’t need to copy it, because, as a function that takes a block parameter, that function is responsible for copying it if it needs to store it around for later.

But what about passing a block to a function or method whose parameter is of non-block type (like id)? Then that function does not know that its argument is a block, and so will only retain the object if it needs to store it for later, not copy it. In this case, if we know that the function or method will store the object around for later (e.g. with -[NSMutableArray addObject:]), we should pass a copy of the block. Should we always pass a copy? Not necessarily. If we know the function or method will not store the block for later (e.g. to just print the object), it is inefficient to make a copy of the block.

In ARC, the compiler tries to do as much as possible for you. So in the case of returning a stack block (“passing it up”), the compiler knows that returning a copy is always the right thing, so it implicitly does that. That’s why you don’t need to do it yourself anymore.

However, for passing a block to a method or function (“passing it down”), it is not always possible to automatically determine whether copying is needed or not, and extra copying might be inefficient, so the compiler doesn’t do anything automatically; and you the programmer needs to figure it out.

I’ve noticed that in recent versions of the compiler, ARC copies blocks in a lot more situations that I thought, so perhaps they changed the implementation of ARC to pretty much always copy blocks, in order to err on the side of caution, and they believed that the performance cost is not as important. So it is possible that it will work now passing a block directly to addObject: without explicitly copying. But I believe that this was not always the case with ARC, and there is no guarantee in the language for this, or that this behavior will stay in the future.