Why do we need pointer to pointer aka double indirection?

In an effort to better grasp why double indirection is needed, e.g., (NSError **), I wrote up a little sample code:

- (void)doFirstThingWith:(NSMutableString *)string {
    // Set local string pointer to the newly created string.
    // note: This DOES NOT affect the string pointer outside of this scope!
    string = [@"first" mutableCopy];

- (void)doSecondThingWith:(NSMutableString *)string {
    // Directly modify referenced string.
    [string replaceCharactersInRange:NSMakeRange(0, string.length) withString:@"second"];

- (void)doThirdThingWith:(NSMutableString **)string {
    // Update referenced pointer to point to the newly created string.
    *string = [@"third" mutableCopy];

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
    NSMutableString *string = [@"before" mutableCopy];
    [self doFirstThingWith:string];
    NSLog(@"doFirstThingWith: %@", string);
    // doFirstThingWith is basically doing this:
    NSMutableString *string2 = string;
    string2 = [@"first" mutableCopy];    
    NSLog(@"doFirstThingWith: %@", string);

    [self doSecondThingWith:string];
    NSLog(@"doSecondThingWith: %@", string);
    [self doThirdThingWith:&string];
    NSLog(@"doThirdThingWith: %@", string);

The resulting output:

2012-03-24 18:06:37.071 PointerTest[1195:707] doFirstThingWith: before
2012-03-24 18:06:37.072 PointerTest[1195:707] doFirstThingWith: before
2012-03-24 18:06:37.073 PointerTest[1195:707] doSecondThingWith: second
2012-03-24 18:06:37.073 PointerTest[1195:707] doThirdThingWith: third

We see that doFirstThingWith does not update the passed in string, this is because we are actually updating the method’s local string pointer instead of the original string pointer.

In doSecondThingWith, we see that we can update the referenced object and have the changes stick. This concept is already familiar to most of us.

In doThirdThingWith, we use a pointer to the original string pointer. This way, we can update the original pointer to point to a newly created string. Using double indirection gives us a mechanism to return newly created objects via method arguments, this being one of its practical uses.

Check out these links for more information:


The mysterious case of an unexpectedly changing NSString attribute

So I had a vanilla Core Data entity with a @property (nonatomic, retain) NSString *text property and a NSTextView *textView used to edit text that would be stored to this value. Initialization looked something like textView.string = model.text and saving looks like model.text = textView.string in textDidEndEditing:.

All good right? Wrong. The value wasn’t sticking. It was changed even though the model’s setter without ever being called. Can you guess why?

It took me wayy too long to debug, but finally… checking out NSText’s string getter method, we see:

For performance reasons, this method returns the current backing store of the text object. If you want to maintain a snapshot of this as you manipulate the text storage, you should make a copy of the appropriate substring.

Tracing NSLog(@"%@", [textView.string class]) we see it is actually an instance of NSBigMutableString. This means both the text editor and entity now hold a reference to the same mutable NSString. Basic CS101, duh! There are two possible fixes: Define the string property using copy vs retain, @property (nonatomic, copy) NSString *text or manually copy the string when setting the value like model.text = [textView.string copy]. See this Stack Overflow post for more info on when to use retain/copy on NSString.