Date Formatter


In the showCurrentTime: method the NSDateFormatter seems to be declared differently to other objects (and never released?)

	static NSDateFormatter *formatter = nil;
	if (!formatter) {
		formatter = [[NSDateFormatter alloc] init];
		[formatter setTimeStyle:NSDateFormatterShortStyle];

Can you explain this further?




The variable formatter is declared as static and therefore exists the entire time your application is running. It is initialized to nil when the application is loaded into memory. The first time showCurrentTime: is executed, the if statement will evaluate to true and a new instance of NSDateFormatter will be created and configured. The variable formatter is then set to point at this new object.

So, you have a permanent variable named formatter that points at an NSDateFormatter object.


That explains it!



ps: Absolutely loving the book.


[quote=“Padraig”]That explains it!

ps: Absolutely loving the book.[/quote]

nods and agrees!



I was pondering this response to the OPs question, because I’m not sure I understand fully why there is no need for decalloc in this instance. (Pun intended. :slight_smile: )

Okay, as a static that makes sense. Isn’t the object (an instance of NSDateFormatter) allocated on the heap, as with all Obj-C objects?

Singleton pattern, no problem there.

Permanent for the life of the application. So this implies that the OS clears the application’s heap memory (which includes this static variable) after the app is terminated? Does that mean memory leaks are only valid during the life of the application?


Correct, when an application launches the OS allocates memory for the application and that memory is split into three segments: the stack (where local variables, return values, all things related to calling a function are stored), the data segment (also known as the code segment, this is where instructions are stored) and heap.

I’m glossing over a few things here, but the general gist of these segments are as follows:

Memory in the code segment is invariable. You don’t have to worry about it.

Memory in the stack is handled automatically, that is, when you call a method, a chunk of the stack (called a frame) is allocated. Any local variables or return values are stored here and when the method exits, the frame is destroyed. You don’t have to worry about it.

The heap is where you dynamically allocate memory as needed. All Objective-C instances are allocated from the heap. You must manage this memory manually.

When the application terminates, the entire chunk of memory allocated to your application (stack, heap, data) is returned to the OS for use by another application. Therefore, the only reason you manage memory is because you want to be able to allocate objects while your application is running. If you just kept using memory from the heap, your application eventually would not be able to allocate any more objects. And then it would crash.