mikeash.com pyblog/friday-qa-2009-05-22-objective-c-class-loading-and-initialization.html comments

mikeash - 2014-05-30 17:23:39

Fri, 30 May 2014 17:23:39 GMT

Good question! If it's reasonable, I'd put an explicit "setup" call somewhere convenient, like your app delegate. Implicit can be nice, but no need to overdo it. Absent that, I'd put a small amount of code in +load that then use dispatch_async or CFRunLoopPerformBlock to schedule the real code for execution once the main runloop starts up. It should be safe to use these APIs from +load since they're lower level, and frameworks that you link to are guaranteed to be initialized first.

@Ahti333 - 2014-05-30 15:20:01

Fri, 30 May 2014 15:20:01 GMT

@mikeash Do you have any recommendation for code that needs to run in a sane environment like +initialize, but needs not to run lazily?

My case: A class that needs to register itself to some other class from the same library, so in +load, I can't be sure that this other class is loaded yet, and I can't use +initialize becuase the class might never get messages then.

Walt Sellers - 2014-04-30 15:50:49

Wed, 30 Apr 2014 15:50:49 GMT

@scottcorscadden

There is no need to add dispatch_once(). It is already provided at least since iOS 6 and presume the same for Mac OS X. You can put a breakpoint in +initialize and see it in the stack trace.

(I recall testing iOS 5 and found that it had acquired a pthread_mutex lock before calling +initialize)

@scottcorscadden - 2013-10-25 14:46:57

Fri, 25 Oct 2013 14:46:57 GMT

Hey, a quick update (improvement?) to this with dispatch_once here might be good, per http://stackoverflow.com/a/11555869/297472



+ (void) initialize {

    static dispatch_once_t onceToken;

    dispatch_once(&onceToken, ^{

        // <do stuff here once, Johnny-Dangerously style>

    });

}

Great work btw.
./scc

Avi - 2013-08-28 13:35:48

Wed, 28 Aug 2013 13:35:48 GMT

@bob

That just points to NSCalendar not setting currentCalendar via +load.

bob - 2013-04-20 06:06:45

Sat, 20 Apr 2013 06:06:45 GMT

@Mike Ash:
"You really can't call out to any other Objective-C classes, because they may rely on +load too, and yours might run first. "

However, that seems to contradict what you said in your article above: "The good news is that frameworks you link to are guaranteed to be fully loaded by this point, so it's safe to use framework classes." Since Billy Gray's category is in his framework, and it links against Foundation framework, shouldn't that mean NSCalendar's currentCalendar stuff (which is in Foundation) should have already been "+load"ed?

Philippe Converset - 2013-04-19 06:45:35

Fri, 19 Apr 2013 06:45:35 GMT

Any thought about using +initialize to create a singleton with something like this?



static WhateverClass *sharedInstance;



+ (void)initialize

{

   if(self == [WhateverClass class])

   {

       sharedInstance = [[self alloc] init];

   }

}

It would mean we can get rid of all these ugly dispatch_once! It looks too good to be true!

Billy Gray - 2012-04-04 15:51:20

Wed, 04 Apr 2012 15:51:20 GMT

Ah, very nice idea, didn't know that was out there. Thanks, Mike!

mikeash - 2012-03-31 18:31:51

Sat, 31 Mar 2012 18:31:51 GMT

The +load method can be dangerous like that. You really can't call out to any other Objective-C classes, because they may rely on +load too, and yours might run first.

My recommendation would be to use dispatch_once to lazily initialize your static variable. The additional overhead is insignificant and you completely avoid problems like this.

Billy Gray - 2012-03-28 17:28:25

Wed, 28 Mar 2012 17:28:25 GMT

FWIW, I've got a category on NSDate (NSDate+Helper) and at some point one of the contributors added code to use a shared, static NSCalendar object on the category, instantiated in the +load method, by calling [NSCalendar currentCalendar]. This worked fine on Debug configuration (iOS 5.1, Xcode 4.3.1, unsure if earlier versions are affected), but in Release configuration, +load must be getting called earlier than expected, perhaps before there is a currentCalendar, so it was always nil! Devil of a thing to debug, dug it up by sticking some NSLog statements in there to figure out what was going on. Certainly would appreciate any ideas on how it might be approached, for now I just removed the use of a static calendar.

More info here if anyone wants to look at the code:
https://github.com/billymeltdown/nsdate-helper/issues/7

Cheers!

HCOD Rayman - 2012-03-20 20:46:53

Tue, 20 Mar 2012 20:46:53 GMT

Ah, I see. You learn something new every day someone teaches you something you didn't already know. Thanks man

mikeash - 2012-03-20 14:48:38

Tue, 20 Mar 2012 14:48:38 GMT

In a class method, self refers to the class.

HCOD Rayman - 2012-03-20 07:47:52

Tue, 20 Mar 2012 07:47:52 GMT

Im slightly confused here... + (void) initialize is a class method, so how can you access the self variable?

mikeash - 2011-09-20 19:04:20

Tue, 20 Sep 2011 19:04:20 GMT

There is no such prefix-matching behavior, no. I'd suggest spending some quality time with the debugger to figure out what's calling these.

PearlWhite88 - 2011-09-20 18:30:56

Tue, 20 Sep 2011 18:30:56 GMT

Will the function names that starting with initialize and load will also get while loading. Because I m seeing a strange behaviour where a function with name intializeX got called on itself.

Thanks

Steven O'Toole - 2009-05-24 09:32:13

Sun, 24 May 2009 09:32:13 GMT

Thanks Joachim.

Joachim Bengtsson - 2009-05-24 06:01:34

Sun, 24 May 2009 06:01:34 GMT

Gah, tr.im messed up those urls... The full URLs are
http://www.friendlystapler.se/browser/RMS/trunk/Source/Include/Utility/StaticInitializer.h
http://www.friendlystapler.se/browser/RMS/trunk/Source/Implementation/Utility/StaticInitializer.cpp

Sorry for the double post

Joachim Bengtsson - 2009-05-24 05:54:19

Sun, 24 May 2009 05:54:19 GMT

Steven: The memory is reclaimed by the application terminating ;) If you really need to do some cleanup (remove cache file or something), register an atexit() function, or subscribe to the applicationWillTerminate notification.

Mike: I love your Q&A's! Didn't know about +load, thanks :)

Back when I "coded" in C++, I wrote a StaticInitialization class that one could inherit from to get the equivalent of +load (it used a macro to define a static int being initialized by a function call). It had a function called require() that would throw an exception if the required class hadn't been +load'ed, which would be caught by that global initialize function and the throwing initializer would be put on a queue to be checked again once the require()'d class was +load'ed. Phew! It actually worked, too!
Hm, come to think of it, I even have the source here: http://tr.im/static_h http://tr.im/static_cpp

Steven O'Toole - 2009-05-24 02:04:26

Sun, 24 May 2009 02:04:26 GMT

Thanks for the article. I have been wondering about +initialize. I can't find a corresponding de-initialize. If I allocate objects, where do they get cleaned up?

For example:

-------

static NSDateFormatter *dateFormatter = nil;
static NSCalendar *gregorian = nil;

@implementation WhatEver

+ (void)initialize {
    if(self != [WhatEver class]) { return;    }
    dateFormatter = [[NSDateFormatter alloc] init];
    [dateFormatter setDateFormat:@"MMM dd, yyyy"];
    gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
}