views:

64

answers:

1

I'm currently working on a Sudoku application, the numbers are stored within a Multi-Dimensional NSMutableArray of NSNumbers. I keep an array in my SudokuGridView, for displaying the numbers in the grid. When it comes time to solve the puzzle, I pass a [grid numberGrid] to a subclass of NSOperation I've created that solves the puzzle.

The grid's array is defined as a property as such:

@property (readonly) NSMutableArray *numberArray; 

When passing it to the sudoku grid solver I go:

MESudokuSolver *solvePuzzleOperation  = [[MESudokuSolver alloc] initWithPuzzle: [grid numberArray]];

initWithPuzzle is defined as so:

- (id)initWithPuzzle:(NSMutableArray *)puzzleArray  {
    if(self = [super init]) {
        puzzle = [[NSMutableArray alloc] initWithArray: puzzleArray];
    }
    return self;    
}

When I then convert the puzzle to a primitive int array to solve it, and then back into the puzzle NSMutableArray. What's funny, is that now, the grid's NSMutableArray now has the solution... Which means that somehow inside the MESudokuSolver the grid's array is being modified. So I did some investigation, the pointer to the array that is passed into the MESudokuSolver instance is different than the MESudokuSolver's puzzle NSMutableArray. Strange, right? I know.

Upon FURTHER investigation, the pointer to the NSNumbers inside the arrays with different pointers are actually the SAME.

To you StackOverflow, I ask, WTF?

+1  A: 

When you initialise an array with the contents of the another array, the contents of both arrays will reference the same objects. What you want to do is perform a deep copy. This ensures that each array references its own copy of the object, so that if you modify the object in one array, it does not affect the object in the other array because they are actually different objects. This applies even to arrays of arrays. There are a number of approaches to performing deep copies. Since you want mutable copies of your mutable arrays inside your mutable array, it is a little trickier, but easy nonetheless:

// Implemented as a free function here, but this is not required.

NSMutableArray *MECopyGrid(NSMutableArray *outer)
{
    NSMutableArray *result = [[NSMutableArray alloc] initWithCapacity:[outer count]];

    for (NSMutableArray *inner in outer)
    {
        NSMutableArray *theCopy = [inner mutableCopy];
        [result addObject:theCopy];
        [theCopy release];
    }

    return result;
}

Beware also of NSNumber optimisations. Cocoa (and I assume Cocoa Touch also) caches a few different NSNumber instances. Since NSNumber instances are immutable, if you ask for [NSNumber numberWithInteger:1], Cocoa may give you a reference to an existing instance containing the same value. If you notice that NSNumber instance pointers are the same, it is likely because Cocoa has given you an old instance. This would save memory especially in situations like yours (without optimisations you would need 81 independent instances of NSNumber, but with optimisations you'll need at most only 9).

dreamlax
Thanks! I've never actually run into this issue before, probably because I've never worked with multidimensional NSArrays before.If I could ask a quick question to clarify here... why is it that if you have a one dimensional array say of... NSStrings, that those strings are actually copied in memory and not modified directly from another instance?
Matt Egan
@Matt Egan: I'm not exactly sure what you mean. If you have an array of immutable strings, they will likely never be copied in memory. Since nothing can modify an immutable string, a `copy` becomes a simple `retain`. If you create a copy of an array containing immutable strings, both arrays will contain references to the same immutable strings. The only time when modifying objects is cause for concern is when your array contains *mutable* objects. If you want an object to maintain mutable but you want nothing else to change it, you must get a `mutableCopy`.
dreamlax
That makes total sense, thanks again!
Matt Egan