Creating, Initializing, Allocating

The first major thing that jumps out to those new to Obj-C is the little plus (+) or minus (-) sign sitting in front of methods. I’ll make use of the NSNumber class throughout this tutorial since it’s simple and it can also be useful in real programming.
If you look into the Apple documentation for NSNumber you’ll find both “Creating an NSNumber Object” and “Initializing an NSNumber Object”. What the heck is the difference there? Take a look!

// These would be found as part of the interface of NSNumber
// Creating an NSNumber
+ (NSNumber *)numberWithInt:(int)value;

// Initializing an NSNumber
- (id)initWithInt:(int)value;

Hmmmm, there isn’t much difference there but those little (+/-) are very important. First off a little bit of terminology, those methods starting with the (+) are called class methods and the ones with (-) are called instance methods. In simple terms this means you need to have an instance of a class to be able to use the (-) instance methods. This means that to use those initialization instance methods we have to first allocate our class. It’s easiest to see if we look at an example.

// Use a class method to get a new NSNumber
// Using
//	+ (NSNumber *)numberWithInt:(int)value;
NSNumber *newNumber = [NSNumber numberWithInt:5];

// Calling an instance method on our new number
NSLog(@"%d", [newNumber intValue]);

// Allocating and initialization of NSNumber
// Using
//	- (id)initWithInt:(int)value;
NSNumber *newAllocedInitNumber = [[NSNumber alloc] initWithInt:5]];

// Calling an instance method on our other new number
NSLog(@"%d", [newAllocedInitNumber intValue]);

So we can see the difference in use here, but initially it looks like we get the same usage for both of our new numbers, the NSLog calls in both cases will print out a “5″. So why should we care about all of this? If this was all the code we have then our program would have a memory leak! Despicable! A memory leak in such a simple little piece of code. That [NSNumber alloc] call is the issue here, this means that our newAllocedInitNumber is being retained; it will hang around forever. We can look at a quick fix for this and hopefully it should make a little more sense. There’s also some nuances about our newNumber object but we’ll go over that in a little bit.

// Allocating and initialization of NSNumber
// Using
//	- (id)initWithInt:(int)value;
NSNumber *newAllocedInitNumber = [[NSNumber alloc] initWithInt:5]];

// Calling an instance method on our other new number
NSLog(@"%d", [newAllocedInitNumber intValue]);

// All done with our new number, lets smash that memory leak
[newAllocedInitNumber release];

Fixed! In this case it’s really just that simple and gives us a great general rule to follow. If you alloc you must release. Make sure you’ve always got that one in the back of your brain. If you alloc you must release.

Now let’s get back to the newNumber object and see what’s happening there. There’s no memory leak for this guy. In fact there’s nothing wrong with it at all, so what is there to talk about? Autorelease. When you create an object in this way it will be automatically released for you. Sounds great; and it is! For the beginner and for a lot of programs that’s all you need to know and you won’t really need to worry about manually managing your memory. Nothing in life is free though and the same is true for auto release. You must remember that you can’t be sure about how long any auto released object will hang around for so it might possibly sit around for awhile taking up memory before it gets released. If you’re writing a game or some other memory intensive program this may matter to you.

Dealloc to the Rescue!

Now that we understand a little bit about how our memory is or isn’t being managed we can look at an another important example that you’ll be sure to come across. You want to make a spiffy new class that holds onto an NSNumber so you can do fancy things with it at a later time. What does that look like? Maybe something like this.

// Declare our spiffy new class
@interface SpiffyClass : NSObject {
	NSNumber *fancyNumber_;
}
@end

// Implement our spiffy new class
@implementation SpiffyClass
- (id) init {
	// A little bit of initialization, this is generally how most of your init methods will start
	if ((self=[super init])) {
		fancyNumber_ = [[NSNumber alloc] initWithInt:111];
	}
	return self;
}

// Doing fancy things with a fancy number
- (void)fancyPants {
	NSLog(@"Fancy %d pants", [fancyNumber_ intValue]);
}
@end

Alright, we have a sparkly new SpiffyClass declaration with our fancyNumber_ object and a call to our fancyPants method will result in the logged message “Fancy 111 pants”. Everything looks fine and dandy here, let’s move on. Wait! Another memory leak is lurking here. We were so close! Remember our little rule, if you alloc you must release. We’re missing our release. Let’s try again.

// . . . interface is the same

// Implement our spiffy new class
@implementation SpiffyClass
- (id) init {
	// A little bit of initialization, this is generally how most of your init methods will start
	if ((self=[super init])) {
		fancyNumber_ = [[NSNumber alloc] initWithInt:111];
	}
	return self;
}

// Doing fancy things with a fancy number
- (void)fancyPants {
	NSLog(@"Fancy %d pants", [fancyNumber_ intValue]);

	// We must remember, if we alloc then we release
	[fancyNumber_ release];
}
@end

Hmmm. Not too bad, we remembered our rule. Let’s try printing our fancy pants message 2 times. Crash, burn, blech! What happened? Trying to call fancyPants more than once will try to release the fancyNumber_ object more than once. Since it’s already been released and it was only allocated once this can cause some problems. (This would be a good point to look up retain count, but I won’t go over it here). How then do we know when to release our fancyNumber_ object? We probably want to hold onto fancyNumber_ until SpiffyClass dies.

// . . . interface is the same
// . . . init is the same

// Ahhhh, I'm dying!
- (void)dealloc {
	[fancyNumber_ release];

	// You'll pretty much always need this
	[super dealloc];
}

// Doing fancy things with a fancy number
- (void)fancyPants {
	NSLog(@"Fancy %d pants", [fancyNumber_ intValue]);
}
@end

Adding the dealloc method is what we need here. dealloc is called automatically whenever an instance of an object gets released. No more memory leaks, no more crashing. Fantastic!

Hopefully this little beginner tutorial is helpful to get you started on the road to understanding memory management in Objective-C. Pages and pages could be written about memory management and some key topics that I skipped over include, retain count, what is super dealloc, and more about auto release and auto release pools. In the future we’ll be covering more of these topics in depth and piece-meal so check back often.