Posts Tagged ARC

Asynchronous Design Patterns with Blocks, GCD and XPC

This is my notes/interpretation of WWDC 2012 Session 712.

Read the rest of this entry »

Tags: , , , ,

Strong reference cycles and blocks

If a block refers to a member of an object then the blocks takes ownership of the object. If the object has also taken ownership of the block to keep it alive for at least the lifetime of the object then this creates a strong reference cycle. Possible solutions are:

  • Create a local variable within the scope where the blocks is implemented or have something like a cancel method on the object that nils the member that is the one that owns the block.
  • Or you can use weak references in the scope where the block is implemented and then assign a strong reference within the block scope and check to see if the reference is nil or not before deciding on what work to do within the block.

Read the rest of this entry »

Tags: ,

Experimental ARC

To help better understand Automatic Reference Counting (ARC) I thought I’d write a collection of routines that highlight what happens in various different situations. I am taking advantage of the fact that a weak pointer becomes nil when the object it points to is deallocated.

The rule that the compiler is keeping to is to make sure that any object that is pointed to by a strong pointer will not be deallocated, and once the object no longer has any strong pointers pointing to it, it will be deallocated soon after. How this is achieved is an implementation detail and many of the routines below highlight different aspects of how the implementation is achieved. As such you should never rely on any object not being deallocated because you believe it will not be deallocated because it is still retained within an autoreleasepool as is demonstrated in the following code. This is important because how the goal is achieved of keeping an object alive over return boundaries is an implementation detail and the implementation can change in the future. For blocks the behaviour will be unreliable as you don’t what is between your code implementing the blocks and where the block gets called, there could for instance be one or more autoreleasepools.

One of the main things I got out of doing this is a better understanding of why I need to use autoreleasepools.

Can you work out what the last NSLog line for each routine will output? The answers are at the end.

One thing to note before reading the code and trying to determine what the output is, is that passing a weak pointer to a function (NSLog for example) will result in the object pointed to by the weak pointer being retained and put into the autoreleasepool. Also if “%@” gets a nil string it will output “(null)”.

Read the rest of this entry »

Tags: , ,

Learning ARC

Automatic Reference Counting (ARC) is a memory management feature for managing Objective-C objects. From Apple we first had manual reference counting which leaves the coder with the responsibility of managing Objective-C objects. Apple decided this was unsatisfactory and tried garbage collection and garbage collection proved to be unsatisfactory, so Apple replaced it with ARC. I don’t think ARC is the perfect solution to memory management but I think it is good enough for it to be Objective-c’s long term solution to memory management.

This is basically my notes as I try and learn ARC. For those of you familiar with Apple’s documentation much of this will be recognizable.

An alternative tutorial for ARC is this ARC tutorial by Mike Ash. This blog post by Mugunth Kumar is also good.

Read the rest of this entry »