Often, one will hear a programmer exclaim over linker errors or runtime dynamic-load errors that appeared only when an Xcode target was changed from Debug to Release configuration (or from Development to Deployment in older projects). The remarks often take the form of "it worked correctly until I switched to Release, so there must be something wrong with the Release configuration." 
 
Well, no; it wasn't working correctly. The flaw was also present in the Debug configuration, and your application was walking dead when you ran it in the Debug configuration.  
 
The culprit — if there is one — is ZeroLink. ZeroLink, you remember, is a feature that the Debug configuration uses to speed the process of getting a project compiled and running. It does this by skipping virtually all of the work of the linker, leaving the linkage of individual objects to when those objects are used while the program is run. If your project never defines the function foo(), and you never call foo() when you run the Debug version, the application will "run fine." The lack of the definition will never be noticed. 
 
There are two solutions. One might be to exercise 100% of your application while in your Debug phase. Then every module will be loaded, and any that can't be loaded will trigger a run-time error. 100% code coverage is a good thing if you want your debugging phase to debug the whole application, but it isn't practical in every run of the application. 
 
The other solution is to turn ZeroLink off once in a while. Without ZeroLink, building a target will put the application through the full process of linking. One of the services a linker performs is to verify that every symbol you use is defined somewhere. If definitions can't be found for some functions or variables, the linker halts the build with an error message that lists the objects it couldn't find. 
 
The summary view of build errors in the project window or Build Results window won't be detailed enough to include the list of symbols that weren't defined. Open the detailed build log (third button at the bottom of the summary in the Build Results window), where you can find the full text of the linker error, including the missing symbols. 

Posted by: Fritz Anderson

@ January 26, 2006 2:31:17 PM CST ( )

I read a lot of mailing-list messages. There are two sorts of messages that turn up as often as twice a week. Both are superficially technical, but have these common themes: 
 

In my work for a prominent software company, I have an exceedingly subtle and difficult task to perform. I have not read any of the hundreds of pages relevant to my question, preloaded and indexed for me, in my computer. Please write my program.

 
or 

I am a senior programmer in an extensive Macintosh project for a famous software company, but am barren of knowledge so elementary and foundational that even a thoughtful guess would adequately answer my question. Please read the manuals to me.

 
 
Both have the same coda: 
 

Answer me immediately. I will repeat this message every two hours. I may stop if I get a response.

 
 
Often, the famous company is one that famously substituted their current programming staff for their previous one. So these requests often amount to, "I took your job. Please continue to do it for free, so your ex-bosses will think I am competent." 
 
Now see here: The people responding to questions on mailing lists are volunteers, who are (or ought to be) highly-paid for their regular work as developers. They are not subject to your demand that they drop everything and turn their hands to work you should be doing yourself.  
 
Stop it. 
 
(I find I write more in dispraise than praise, which I think may be a character flaw. At least I can segregate the bile in its own category.) 

Posted by: Fritz Anderson

@ January 25, 2006 3:24:33 PM CST ( )

A distressed writer to a mailing list says of a debugger, 

 
I can set the word size to 1 and the column count to 16, then resize the window and columns but then I loose the grouping of bytes and it becomes tedious to count out to the middle of a line. 

 
It must be tiresome to "loose the grouping of bytes." Once they get loose, there's no telling where they'll get to. A grouping of bytes, once set loose, may lodge under the '?' key, and where would you be then? How would you indicate that you really want an answer to a question by putting three or four question marks at the end? 
 
Many's the time I wouldn't answer a question, but gosh darn it, it was asked with five question marks, and how can you resist that? 

 

1. If you come upon an event whereby something is lost (not loost), you say you lose it. Not loose it.
 

2. If you are counterfeiting a ten-dollar bill, you do not make it more of a ten-dollar bill, as I supposed when I was five, by writing lots of "10"s all over it. By the same token, you cannot increase the question-ness of a sentence by appending lots of question marks. One per sentence gets you all the question you're going to get.

 
Thank you for your attention. 

Posted by: Fritz Anderson

@ January 18, 2006 12:52:18 PM CST ( )

The Miss Information web log is very entertaining. The log focuses on the acerbic observations of a library clerk (apparently a different grade of employment from librarian where she works) in an urban library. Her exact employer is ascertainable from internal evidence, but as she doesn't mention it outright, I won't spill it here.  
 
Miss Information is a Major Babe. 

Posted by: Fritz Anderson

@ January 1, 2006 3:39:19 PM CST ( )

The first thing to remember about Step into Xcode is that it's a book about Xcode. Because Xcode is designed around the programmer's workflow, the first half of the book takes you through the typical workflow of designing and implementing a Cocoa application in Objective-C. 
 
Despite the subtitle of the book, Step into Xcode is not a book about Mac OS X development tout court. It is not a book about languages or frameworks: I go into Objective-C deep enough to make the code examples readable. I explain Cocoa enough to make Xcode's and Interface Builder's features for Cocoa meaningful. 

• Are there better books about Cocoa? Certainly: Any book that is about Cocoa is bound to be a better Cocoa book than a book about Xcode.
 

• I don't cover development for Carbon. This is true, but covering frameworks is not what I set out to do -- I don't cover Cocoa (well) either. The narrative in Part 1 was supposed to demonstrate how Xcode is used; A parallel demonstration for Carbon would be pointless and redundant.
 

• I don't cover the use of Interface Builder for Carbon applications. This is a fair criticism. All I can say is that without a Carbon project to use the resulting NIB, it was hard to fit an example of a Carbon NIB into my narrative.
 

• I don't cover C++. Again, my aim was to explain Xcode, not languages. Also, some of Xcode's features — the class modeler most notably — aren't quite ready for C++. On the one hand, I'd have to discuss those weaknesses (and I think I dissed Xcode enough in the Codewarrior chapter); on the other, I'd expect the weaknesses to be the first things fixed in new versions, and I was reluctant to include material that would go stale during the lifetime of the book.
 

• I don't cover Java. As with Carbon, a parallel narrative focused on Java would be mostly redundant (for my purposes). Also, Xcode is frankly a mediocre tool for Java development. Use Eclipse instead.

 
… but if you learn to program in Mac OS X along the way, I'll be glad to take the credit! 

Posted by: Fritz Anderson

@ January 1, 2006 2:45:22 PM CST ( )