Actually, it’s the most useful code I’ve extended; credit for the core idea goes to Dave Dribin with his Handy NSString Conversion Macro.
LOG_EXPR(x)
is a macro that prints out x
, no matter what type x
is, without having to worry about format-strings (and related crashes from eg. printing a C-string the same way as an NSString
). It works on Mac OS X and iOS. Here are some examples,
LOG_EXPR(self.window.screen);
self.window.screen = <UIScreen: 0x6d20780; bounds = {{0, 0}, {320, 480}}; mode = <UIScreenMode: 0x6d20c50; size = 320.000000 x 480.000000>>
LOG_EXPR(self.tabBarController.viewControllers);
self.tabBarController.viewControllers = (
“<UINavigationController: 0xcd02e00>”,
“<SavingsViewController: 0xcd05c40>”,
“<SettingsViewController: 0xcd05e90>”
)
Pretty straightforward, really. The biggest convenience so far is having the expression printed out, so you don’t have to write out a name redundantly in the format string (eg. NSLog(@"actionURL = %@", actionURL)
). But LOG_EXPR
really shows it’s worth when you start using scalar or struct
expressions:
LOG_EXPR(self.window.windowLevel);
self.window.windowLevel = 0.000000
LOG_EXPR(self.window.frame.size);
self.window.frame.size = {320, 480}
Yes, there are expressions that won’t work, but they’re pretty rare for me. I use LOG_EXPR
every day. Several times. It’s not quite as good as having a REPL for Cocoa, but it’s handy.
How It Works
The problem is how to pick a function or format string to print x
, based on the type of x
. C++’s type-based dispatch would be a good fit here, but it’s verbose (a full function-definition per type) and I wanted to use pure Objective-C if possible. Fortunately, Objective-C has an @encode()
compiler directive that returns a string describing any type it’s given. Unfortunately it works on types, not variables, but with C99 the typeof()
compiler directive lets us get the type of any variable, which we can pass to @encode()
. The final bit of compiler magic is using stringification (#
) to print out the literal string inside LOG_EXPR()
‘s parenthesis.
The Macro, Line By Line
1 #define LOG_EXPR(_X_) do{\ 2 __typeof__(_X_) _Y_ = (_X_);\ 3 const char * _TYPE_CODE_ = @encode(__typeof__(_X_));\ 4 NSString *_STR_ = VTPG_DDToStringFromTypeAndValue(_TYPE_CODE_, &_Y_);\ 5 if(_STR_)\ 6 NSLog(@"%s = %@", #_X_, _STR_);\ 7 else\ 8 NSLog(@"Unknown _TYPE_CODE_: %s for expression %s in function %s, file %s, line %d", _TYPE_CODE_, #_X_, __func__, __FILE__, __LINE__);\ 9 }while(0)
- The first and last lines are a way to put
{}
‘s around the macro to prevent unintended effects. Thedo{}while(0);
“loop” does nothing else. - First evaluate the expression,
_X_
, given toLOG_EXPR
once, and store the result in a_Y_
. We need to usetypeof()
(which had to be written__typeof__()
to appease some versions of GCC) to figure out the type of_Y_
. _TYPE_CODE_
is c-string that describes the type of the expression we want to print out.- Now we have enough information to call a function,
VTPG_DDToStringFromTypeAndValue()
to convert the expression’s value to a string. We pass it the_TYPE_CODE_
string, and the address of_Y_
, which is a pointer, and has a known size. We can’t pass_Y_
directly, because depending on what_X_
is, it will have different types and could be of any size. VTPG_DDToStringFromTypeAndValue()
returnsnil
if it can’t figure out how to convert a value to a string.- Everything went well, print the stringified expression,
#_X_
, and the string representing it’s value,_STR_
. - otherwise…
- The expression had a type we can’t handle, print out a verbose diagnostic message.
- See line 1.
The VTPG_DDToStringFromTypeAndValue()
Function
See the source in VTPG_Common.m:
It’s derived from Dave Dribin‘s function DDToStringFromTypeAndValue()
, and is pretty straightforward: strcmp()
the type-string, and if it matches a known type call a function, or use +[NSString stringWithFormat]:
, to turn the value into a string.
The First Step Twords Fixing Your Macro Problem is Admitting it…
So yeah, maybe I went a little wild with macros here…
But it took out some WET-ness of the original code, and prevents me from accidentally mixing up types in a long wall of if
s, eg.
else if (strcmp(typeCode, @encode(NSRect)) == 0) { return NSStringFromRect(*(NSRange *)value); } else if (strcmp(typeCode, @encode(NSRange)) == 0) { return NSStringFromRect(*(NSRange *)value); }
If I were cool, I’d use NSDictionary
s to map from the @encode
-string to an appropriate format string or function pointer. This is conceptually cleaner; less error-prone than using macros; and almost certainly faster. Unfortunately, it gets a little tricky with functions, since I need to deference value
into the proper type.
One final note from my testing, I could do away with the strcmp()
s, because directly comparing @encode
string pointers (eg if(typeCode == @encode(NSString*))
works. I don’t know if it will always work though, so relying on it strikes me as a profoundly Bad Idea. But maybe that bad idea will give someone a good idea.
Limitations
Arrays
C arrays generally muck things up. Casting to a pointer works around this:
char x[14] = "Hello, world!"; //LOG_EXPR(x); //error: invalid initializer LOG_EXPR((char*)x); //prints fine
__func__
Because it is a static const char []
, __func__
(and __FUNCTION__
or __PRETTY_FUNCTION__
) need casting to char*
to work with LOG_EXPR
. Because logging out a function/method call is something I do frequently, I use the macro:
#define LOG_FUNCTION() NSLog(@"%s", __func__)
long double
(Leopard and older)
On older systems, LOG_EXPR
won’t work with a long double
value, because @encode(long double)
gives the same result as @encode(double)
. This is a known issue with the runtime. The top-level LOG_EXPR
macro could detect a long double
with if((sizeof(_X_) == sizeof(long double)) && (_TYPE_CODE_ == @encode(double)))
. But I doubt this will ever be necessary.
I haven’t actually written any code that uses long double
, because I use NSDecimal
, or another base-10 number format, for situations that require more precision than a double
.
Scaling and Frameworks
Growing LOG_EXPR
to handle every type is a lot of work. I’ve only added types that I’ve actually needed to print. This has kept the code manageable, and seems to be working so far.
The biggest problem I have is how to deal with types that are in frameworks that not every project includes. Projects that use CoreLocation.framework need to be able to use LOG_EXPR
to print out CoreLocation specific struct
s, like CLLocationCoordinate2D
. But projects that don’t use CoreLocation.framework don’t have a definition of the CLLocationCoordinate2D
type, so code to convert it to a string won’t compile. There are two ways I’ve tried to solve the problem
Comment-out framework-specific code
This is pretty self-explanatory, I’ll fork VTPG_Common.m and un-comment-out code for types that my project needs to print. It works, but it’s drudgery. Programmers hate that.
Hardcode type info
The idea is to hard-code the string that @encode(SomeType)
would evaluate to, and then (since we know how SomeType
is laid out in memory) use casting and pointer-arithmetic to get at the fields.
For example:
//This is a hack to print out CLLocationCoordinate2D, without needing to #import <CoreLocation/CoreLocation.h> //A CLLocationCoordinate2D is a struct made up of 2 doubles. //We detect it by hard-coding the result of @encode(CLLocationCoordinate2D). //We get at the fields by treating it like an array of doubles, which it is identical to in memory. if(strcmp(typeCode, "{?=dd}")==0)//@encode(CLLocationCoordinate2D) return [NSString stringWithFormat:@"{latitude=%g,longitude=%g}",((double*)value)[0],((double*)value)[1]];
This Just Works in a project that includes CoreLocation, and doesn’t mess up projects that don’t. Unfortunately it’s horribly brittle. Any Xcode or system update could break it. It’s not a tenable fix.
Areas for Improvement
If there’s some type LOG_EXPR
can’t handle that you need, please jump right in and improve it!
When I have time, I plan to write a general parser for @encode()
-strings. This will let me print out any struct
, which mostly solves the type-defined-in-missing-framework problem, and would let LOG_EXPR
Just Work with types from all kinds of POSIX/C libraries.
Using LOG_EXPR()
in Your Project
Download VTPG_Common.m and VTPG_Common.h from my github repository, and add them to your Xcode project.
Now just add the line #import "VTPG_Common.h"
to your prefix file (named <ProjectName>_Prefix.pch
by default), after the #ifdef __OBJC__
, for example:
#ifdef __OBJC__ #import <Foundation/Foundation.h> // maybe other files, depending on project template... #import "VTPG_Common.h" #endif
Now LOG_EXPR()
will work everywhere in your project.