[cpp]
void (^now)(void) = ^ {
NSDate*date = [NSDatedate];
NSLog(@"The date and time is %@", date);
};
Here's where things get funky. The syntax for declaring a block variable takes somegetting used to. If you've used function pointers, block variables will look familiar. On the right-hand side of the assignment we have our block literal (nothing new there).On the left-hand side of the assignment we've declared a block variable callednow.
The name of the block variable is always preceded by a and in parentheses. Block variables have an associated type. In this case, thenow variable can reference any block that returns no value (the firstvoid) and takes no parameters (the void in parentheses). Ourblock conforms to this type, so we can safely assign it to thenowvariable.
Once we have a block variable in scope, calling the block is just like calling a function. Here's how we call our block:
[cpp]
now();
You could declare the block variable in a C function or Objective-C method, for example,and then call it in the same scope. When the block executes, it prints the current dateand time. So far, so good.
Blocks Are Closures
If that's all there was to blocks, they'd be just like functions. But it turns out that blocks are more than just chunks of executable code. Blocks also capture their surrounding state. That is, blocks are closures: theyclose around variables that are in scope at the time the block is declared. To illustrate, let's change the previous example around a bit by moving the initialization of the date outside the block:
[cpp]
NSDate *date = [NSDate date];
void (^now)(void) = ^ {
NSLog(@"The date and time is %@", date);
};
now();
When you call this block the first time, it behaves exactly like the previous version: it prints the current date and time. But there's a significant difference here. It becomes evident when we change the date and then call the block again:
[cpp]
sleep(5);
date = [NSDatedate];
now();
Even though we've changed the date variable referenced by the block, whenthe block is called it still prints the original date and time. It's as if time stoodstill when the block was declared. And that's effectively what happens. As executionpasses over the point where the block is declared, the block takes a (read-only)snapshot of all the variables in scope that the block uses. You can think of the valueof thedate variable as being frozen inside the block. Therefore, wheneverthe block is called—immediately, 5 seconds later, or just before the appquits—it always prints the original date and time.
Now, the fact that blocks are closures is not particularly interesting in this example. After all, you could have just passed the date as a parameter to the block (more on that next). But closures become really useful when you start passing blocks around to methods because the captured state goes along for the ride.
Block Parameters
Just like functions, blocks can take parameters and return values. Say, for example, we want a block that takes a given number and returns the result of tripling that number. Here's the block literal:
[cpp]
^(intnumber) {
returnnumber * 3;
};
Assigning this block to a block variable called triple looks like this:
[cpp]
int (^triple)(int) = ^(intnumber) {
returnnumber * 3;
};
Again, the tricky pa