Cocoa Programming for Mac OS X - Aaron Hillegass [24]
What Have You Done?
You have written a simple program in Objective-C, including a main() function that created several objects. Some of these objects were instances of LotteryEntry, a class that you created. The program logged some information to the console.
At this point, you have a fairly complete understanding of Objective-C. Objective-C is not a complex language. The rest of the book is concerned with the frameworks that make up Cocoa. From now on, you will be creating event-driven applications, not command-line tools.
Meet the Static Analyzer
One of the handiest tools in Xcode is the static analyzer. The static analyzer uses Apple’s LLVM compiler technology to analyze your code and find bugs. Traditionally, developers have relied on compiler warnings for hints on potential trouble areas in their code. The static analyzer goes much deeper, looking past syntax and tracing how values are used within your code.
Because of the default compiler settings and our careful typing, you should find, if you run the analyzer now, that our application has no issues as it stands. Let’s modify our project settings so that we can better see the static analyzer at work.
As we did before, open the project’s build settings by selecting the project in the project navigator on the left. Then select the lottery target. In the Build Settings tab, find the setting for Objective-C Automatic Reference Counting. Change its value to No (Figure 3.15).
Figure 3.15. Disable Automatic Reference Counting
Now analyze the lottery application. In the Product menu, click Analyze. In the issues navigator, you will see several issues found by the static analyzer; select one and drill down in the tree to examine the analyzer’s thought process (Figure 3.16).
Figure 3.16. The Static Analyzer at Work
In this case, the static analyzer has found a number of memory-related problems in our program because we disabled a feature called automatic reference counting, which we will discuss in the next chapter. This is one of the more useful aspects of the static analyzer: It knows the rules for retain-count memory management in Objective-C, and it can also identify other dangerous patterns in your code.
Leave automatic reference counting disabled for now.
For the More Curious: How Does Messaging Work?
As mentioned earlier, an object is like a C struct. NSObject declares an instance variable called isa. Because NSObject is the root of the entire class inheritance tree, every object has an isa pointer to the class structure that created the object (Figure 3.17). The class structure includes the names and types of the instance variables for the class. It also has the implementation of the class’s methods. The class structure has a pointer to the class structure for its superclass.
Figure 3.17. Each Object Has a Pointer to Its Class
The methods are indexed by the selector. The selector is of type SEL. Although SEL is defined to be char *, it is most useful to think of it as an int. Each method name is mapped to a unique int. For example, the method name addObject: might map to the number 12. When you look up methods, you will use the selector, not the string @"addObject:".
As part of the Objective-C data structures, a table maps the names of methods to their selectors. Figure 3.18 shows an example.
Figure 3.18. The Selector Table
At compile time, the compiler looks up the selectors wherever it sees a message send. Thus,
[myObject addObject:yourObject];
becomes (assuming that the selector for addObject: is 12)
objc_msgSend(myObject, 12, yourObject);
Here, objc_msgSend() looks at myObject’s isa pointer to get to its class structure and looks for the method associated with 12. If it does not find the method, it follows the pointer to the superclass. If the superclass does not have a method for 12, it continues searching up the tree. If it reaches the top of the tree without finding a method, the function throws