Is it ok to use "classic" malloc()/free() in Objective-C/iPhone apps?

I've been playing around with iPhone development for a while, and although it feels a bit awkward when you're a "hard core" .NET developer, it's not all that bad once you get used to it.

In every book I read about Objective-C, there's only talk about retain/release (reference counting) for memory management. As an old-skool C/C++ developer, it seems strange that allocating the "normal" way, using malloc() and free() is only mentioned in some footnotes.

I know that malloc() and free() work in Objective-C, but I'm curious if it is common practice or not. After all, if I want to allocate an array of 100 integers, it seems that this is the most efficient way to do it:

int *array = malloc(sizeof(int) * 100);

memset(array,0,sizeof(int) * 100);

// use the array

free(array);

Is this indeed the best way, or should I avoid plain C memory management?

Solution 1:

There's an Objective-C wrapper around raw memory which I like to use a lot for similar tasks: NSMutableData. It has the benefit of giving you retain/release ownership plus it can grow the array easily (without having you to do the realloc yourself).

Your code would look like:

NSMutableData* data = [NSMutableData dataWithLength:sizeof(int) * 100];
int* array = [data mutableBytes];
// memory is already zeroed

// use the array

// decide later that we need more space:
[data setLength:sizeof(int) * 200];
array = [data mutableBytes]; // re-fetch pointer in case memory needed to be copied

// no need to free
// (it's done when the autoreleased object is deallocated)

Solution 2:

It's perfectly fine -- Objective-C is a strict superset of C, so if you want to write plain C, there's nothing preventing you from doing so. In many cases, it's advantageous to use malloc and free to avoid the overhead of the Objective-C runtime.

For example, if you need to dynamically allocate an array of an unknown number of integers, it's often simpler and easier:

int *array = malloc(N * sizeof(int));  // check for NULL return value!
// use array[0]..array[N-1]
...
free(array);

Versus:

NSMutableArray *array = [[NSMutableArray alloc] initWithCapacity:N];
// use NSMutableArray methods to do stuff with array; must use NSNumbers instead
// of plain ints, which adds more overhead
...
[array release];

I was working on a word game for the iPhone, and we had to load a multi-megabyte dictionary of valid words. The word list was loaded into one giant char array allocated with malloc(), with some clever optimizations to reduce the memory size even more. Obviously for something like this, the overhead of using an NSArray is completely impractical on the limited iPhone. I don't know exactly what the overhead is, but it's certainly more than one byte per character.

Solution 3:

Of course, you can use these functions, because Objective-C is merely a superset of C. However, it is fairly uncommon to do this sort of thing, since Objective-C contains objects and ways to make this easier.

After all, you could write the above code as:

NSMutableArray *array = [[NSMutableArray alloc] init];

//Use the array, adding objects when need be

[array release];

Although you would have to create NSNumber objects to store the ints (since NSArray doesn't allow non-object types to be added), it is generally more common to use objects, because it is easier to move data around, and the array classes are integrated more commonly with other Cocoa classes, and the memory management is generally more straightforward than standard C memory management.

Also, if you start adding or removing objects from the array, then the Cocoa array objects make this much easier to do.

Solution 4:

If you're dealing with standard C types, it's no less common or "OK" than in C. That's how it's done in C, which is a part of Objective-C.

It's also not unusual to write some kind of object wrapper around these things to bring it into harmony with the rest of Cocoa (KVO, memory management, etc.). So you might create an IntArray class that does the mallocing behind the scenes so you can retain and release it as needed. Note that this isn't strictly necessary — it can just be handy if that kind of structure is a major part of your program.