Vincent Gable

CFShow(coreFoundationThingy) will print out a description of coreFoundationThingy to the console. Output looks something like:

{value = w:1186.000000 h:687.000000 type = kAXValueCGSizeType}

If NSLog() is printing something out as an NSCFType, try CFShow().

Or: How to Make NSLog() Useful With Your Objects

Say you have an archaically named NSArray that you want to inspect — it’s easy to do, since NSLog(@"The bestiary is %@", bestiary); prints out the array’s contents

2008-09-16 19:46:06.445 Tester[2678:10b] The bestiary is (
Cheetah,
Pumpa,
Jaguar,
Panther,
Tiger,
Leopard
)

But if you try to NSLog your own object, you get pretty useless output, like

myObject = <MyObject: 0×53f330>

Fortunately, it’s easy to fix! Just implement the method -(NSString*) description; and whatever it returns will be printed by NSLog and GDB (po object, will print object in GDB and the Xcode debugging console).

Here’s an (unfortunately complex) example,

- (NSString*) description;
{
  return [NSString stringWithFormat:@”<%@ %p> = {\n\tquestion=%@,\n\tanswer=%@,\n\tsource=%@\n}”, [self className], self, self.question, self.answer, self.source];
}

output:

myObject = <MyObject 0×53eed0> = {
  question=What is the Best Thing Ever Of All Times, Ever?,
  answer=The Internet!,
  source=http://www.cabel.name/2008/01/2007-cabel-yay-awards.html
}

Useful Formatters and such

These macros have made my debugging-life easer.

%p tells NSLog to print the address of a pointer.

-className returns gives the name of a class as an NSString.

Don’t manually print out a Cocoa struct, ever, there are already NSStringTo* functions to do that for you, like NSStringFromPoint().

NSStringFromSelector() works as advertized (and paired with NSSelectorFromString() is very useful in general).

%lld tells NSLog to print a long long (64-bit integer). See also, printf reference.

%Lf tells NSLog to print a long double. See also, printf reference.

Best Practices

Whenever you make a new object, I strongly recommended immediately implementing a description method, and religiously keeping it up to date (it’s not hard, honest!). This won’t fix bugs, but it will make finding some of them much easier.

I have noticed a pattern in my Cocoa code, which I have been able to simplify. I often print out the value of a variable for debugging. 99 times out of 100, the code looks like this: NSLog(@"actionURL = %@", actionURL);, where actionURL is some variable.

But using the macros, I can say LOG_ID(actionURL);. This is shorter, and non-repetitive.

The macros I use to simplify debugging (2008-09-16):

#define FourCharCode2NSString(err) NSFileTypeForHFSTypeCode(err)

#define LOG_4CC(x) NSLog(@”%s = %@”, # x, FourCharCode2NSString(x))
#define LOG_FUNCTION() NSLog(@”%s”, __FUNCTION__)
#define LOG_ID(o) NSLog(@”%s = %@”, # o, o)
#define LOG_INT(i) NSLog(@”%s = %d”, # i, i)
#define LOG_INT64(ll) NSLog(@”%s = %lld”, # ll, ll)
#define LOG_FLOAT(f) NSLog(@”%s = %f”, # f, f)
#define LOG_LONG_FLOAT(f) NSLog(@”%s = %Lf”, # f, f)
#define LOG_OBJECT(o) LOG_ID(o)
#define LOG_POINT(p) NSLog(@”%s = %@”, # p, NSStringFromPoint(p))
#define LOG_RECT(r) NSLog(@”%s = %@”, # r, NSStringFromRect(r))
#define LOG_SIZE(s) NSLog(@”%s = %@”, # s, NSStringFromSize(s))

Look in assert.h for insight on how to roll your own debugging macros.