Objective-C Blocks

標籤：des   style   blog   http   io   color   ar   os   for   

Objective-C Blocks

All of these examples have been verified with this version of LLVM:

Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)Target: x86_64-apple-darwin11.4.2Thread model: posix

Example A

void exampleA() {  char a = ‘A‘;  ^{    printf("%c\n", a);  }();}

This always works. The stack for exampleA doesn’t go away until after the block has finished executing. So whether the block is allocated on the stack or the heap, it will be valid when it is executed.

Example B

void exampleB_addBlockToArray(NSMutableArray *array) {  char b = ‘B‘;  [array addObject:^{    printf("%c\n", b);  }];} void exampleB() {  NSMutableArray *array = [NSMutableArray array];  exampleB_addBlockToArray(array);  void (^block)() = [array objectAtIndex:0];  block();}

This only works with ARC.

Without ARC, the block is an NSStackBlock allocated on the stack of exampleB_addBlockToArray. By the time it executes in exampleB, the the block is no longer valid, because that stack has been cleared.

With ARC, the block is properly allocated on the heap as an autoreleased NSMallocBlock to begin with.

Example C

void exampleC_addBlockToArray(NSMutableArray *array) {  [array addObject:^{    printf("C\n");  }];} void exampleC() {  NSMutableArray *array = [NSMutableArray array];  exampleC_addBlockToArray(array);  void (^block)() = [array objectAtIndex:0];  block();}

This always works.Since the block doesn’t capture any variables in its closure, it doesn’t need any state set up at runtime. it gets compiled as an NSGlobalBlock. It’s neither on the stack nor the heap, but part of the code segment, like any C function. This works both with and without ARC.

Example D

typedef void (^dBlock)(); dBlock exampleD_getBlock() {  char d = ‘D‘;  return ^{    printf("%c\n", d);  };} void exampleD() {  exampleD_getBlock()();}

This only works with ARC.

This is similar to example B. Without ARC, the block would be created on the stack of exampleD_getBlock and then immediately become invalid when that function returns. However, in this case, the error is so obvious that the compiler will fail to compile, with the error error: returning block that lives on the local stack.

With ARC, the block is correctly placed on the heap as an autoreleased NSMallocBlock.

Example E

typedef void (^eBlock)(); eBlock exampleE_getBlock() {  char e = ‘E‘;  void (^block)() = ^{    printf("%c\n", e);  };  return block;} void exampleE() {  eBlock block = exampleE_getBlock();  block();}

This only works with ARC.

This is just like example D, except that the compiler doesn’t recognize it as an error, so this code compiles and crashes. Even worse, this particular example happens to work fine if you disable optimizations. So watch out for this working while testing and failing in production.

With ARC, the block is correctly placed on the heap as an autoreleased NSMallocBlock.

Conclusions

So, what’s the point of all this? The point is always use ARC. With ARC, blocks pretty much always work correctly. If you’re not using ARC, you better defensively block = [[block copy] autorelease] any time a block outlives the stack frame where it is declared. That will force it to be copied to the heap as an NSMallocBlock.

Haha! No, of course it’s not that simple. According to Apple:

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.

But one of the LLVM maintainers later said:

We consider this to be a compiler bug, and it has been fixed for months in the open-source clang repository. What that means for any hypothetical future Xcode release, I cannot say. 

So, hopefully Apple was describing a workaround for bugs that existed at the time their guide was written, and everything should work smoothly with ARC and LLVM in the future. But watch out. 

But there are incoordination ideas.

"Always use ARC" feels akin to saying "don‘t bother understanding how block lifecycles actually work". Blocks work correctly without ARC, too. If you don‘t understand the difference between stack- and heap-allocated memory, you are in for trouble eventually. In these cases, ARC is just protecting you from the incorrect code, and actually kinda encouraging the poor understanding of the issue.

One real bug here shows up in examples B and C. In both examples, NSMutableArray will retain the blocks. This is a logical error, because you cannot retain stack blocks. This is an obvious and immediate bug, but instead of an exception, its a no-op.

From:http://blog.parse.com/2013/02/05/objective-c-blocks-quiz/

Objective-C Blocks