understanding the use of static in Objective C

[mcclen]

I'm trying to understand the use of static in Objective C, and in particular how to achieve a C, C++, Java like static structure/object and how to initialize it.

Here's what I've got:

#import <Foundation/Foundation.h>

@interface StaticClass : NSObject {

}

+ (NSString *) getStaticString;
+ (NSDate *) getStaticDate;
+ (void) setStaticString:(NSString *) newString;
+ (void) setStaticDate:(NSDate *) newDate;

@end

and

#import "StaticClass.h"

@implementation StaticClass

static NSString * staticString = @"Hello World";
static NSDate * staticDate = nil;

+ (void) initialize {
		//staticDate = [NSDate dateWithTimeIntervalSince1970:0];
	staticDate = (NSDate *)CFDateCreate(NULL,-kCFAbsoluteTimeIntervalSince1970);
}

+ (NSString *) getStaticString {
	return staticString;
}

+ (NSDate *) getStaticDate {
	return staticDate;
}

+ (void) setStaticDate:(NSDate *) newDate {
	staticDate = newDate;
}

+ (void) setStaticString:(NSString *) newString {
	staticString = newString;
}

When I use this class in a simple iPhone application there are two things I don't understand. First the difference between the line commented out in the initialize method and its adjacent statement. When run with the performance tool on the iPhone, the uncommented line produces a reported memory leak, while when the commenting is reversed, the other line does not. The iphone SDK documentation says there is a "toll free bridge" between NSDate and CFDateRef, and while that doesn't necessarily mean memory management equality, what is the difference between the two?

The second item has to do with the use of load versus initialize. When the method currently defined as initialize is defined as load and compiled and used (happens with either date construct), the following error/warning appears in the console:

2010-06-26 10:17:57.650 StaticThings[341:207] *** _NSAutoreleaseNoPool(): Object 0x106140 of class __NSCFDate autoreleased with no pool in place - just leaking
Stack: (0x3374ff83 0x33723973 0x3372393f 0x324122f7 0x293d 0x3138c3d0 0x3138c140 0x2fe01a2b 0x2fe09e35 0x2fe0a29f 0x2fe023d9 0x2fe06b21 0x2fe01785 0x2fe01050)

while if the method is defined as initialize, no error is reported.

Thoughts? Pointers? Suggestions?

Thanks.

[smasher]

dateWithTimeIntervalSince1970 vs. CFDateCreate:
The first one (dateWithTimeIntervalSince1970) creates and object, returns it to you, and "autoreleases" it - that is, adds it to an autorelease pool which usually gets drained at the end of the current event. That object will probably be gone by the time you go to use it, since you did not retain it.

CFDateCreate creates an object that you own - it will not be destroyed until you release it. You never do release it, even in your setStaticDate method, which is why it leaks. More on this later.

+load vs +initialize
Cocoa with love says "Any class can have a +(void)load method and it will be invoked by the runtime when the class is loaded. For normal compiled classes, this occurs during "image loading" (some time before main() is invoked)." This means that the "+load" method may be called before the execution of your program's main function, therefore before any autorelease pool is created. So you can't use an method (like dateWithTime) that requires an autorelease pool in place. The +initialize is called much later, after execution has started but before any messages are sent to this object. You almost surely want initialize.

Your setters
Your setters are not retaining the new object and releasing the old one, so you're going to leak memory every time they're called. You need to release the old object so it can be destroyed if appropriate, and retain the new one so it is not destroyed until you're done with it. A properly written setter might look like this:

+ (void) setStaticDate:(NSDate *) newDate {
	NSDate *oldValue = staticDate;	//keep a pointer to the old value
	staticDate = [newDate retain];	//retain and assign the new value
	[oldValue release];	//release the old value
}

Extra credit
Someone else may stroll by and say "don't do what you're doing, use a singleton" and they might be right - your use of class methods and static variables means you lose out on properties and key-value coding and archiving and some other nice stuff. However your code is pretty clear and it's obvious what it does. The code for a singleton is less obvious, and requires more knowledge of Cocoa internals to understand. Still, you might want to look at it in the future.