I just released a compatibility update for Kobold2D since there were numerous compiler warnings and errors introduced in Xcode 4.4.
Almost all of the issues were simply the compiler being more adamant about using the correct type specifiers in format strings. For example using %i for an unsigned integer or %u for an unsigned long type would bring up warnings. The solution is to use either the correct format specifier or casting the value. The latter is preferable if the underlying type changes depending on the platform. For example NSUInteger is unsigned int for iOS but on Mac 64-Bit it’s actually unsigned long.
You can get the updated Kobold2D v1.1.2 and v2.0.3 versions from the Kobold2D Downloads page. Continue reading »
Have a look at the following code example:
|
1 2 3 |
NSString* str1 = NSString.alloc.init; NSString* str2 = str1.copy; NSLog(@"str1: %@, str2: %@", str1.capitalizedString, str2.description); |
Did you find it strange somehow? Odd perhaps? Then you may be surprised to learn that this is perfectly valid Objective-C code. Go ahead and try it in your project. As long as the project is set to use the Apple LLVM Compiler this will work.
I have no doubt that automatic reference counting (ARC) is the next big leap forward for Objective-C since the introduction of Objective-C 2.0. ARC allows you to put the burden of memory management on the (Apple LLVM 3.0) compiler, and never think about retain, release and autorelease ever again.
Since many user’s first experiences with ARC will be trying to convert an existing app, they will learn the hard way that converting existing code to ARC is not a fire & forget operation. And since this is the Internet, there’s also a lot of assumptions, false statements and other myths revolving around ARC going around.
So here’s just about everything you need to know about ARC, and some ARC-mythbusting too.
- Development Requirements for ARC apps
- Minimum Deployment Targets for ARC apps
- Required Deployment Targets with zeroing weak references
- How to enable ARC in your project
- Compile errors after switching to LLVM 3.0
- Getting third party libraries to build with ARC
- Converting an existing app to ARC
- “Cannot Convert to Objective-C ARC”
- Fixing pointer types in C structs
- Fixing C/C++ pointer transfers with bridged casts
- Fixing NSAutoreleasePool with @autoreleasepool
- Methods you can’t call (or override) anymore
- You can still override -(void) dealloc {}
- Property naming restriction
- New Property keywords: strong and weak
- ARC forbids synthesizing a readonly property without ownership qualifier
- For experts: detecting at compile-time if ARC is enabled
- For experts: allow use of ARC keywords with ARC disabled
- Myth: ARC has not been proven reliable
- Myth: ARC takes away control over Memory Management
- ARC Reference Documentation
I haven’t been able to find a list of all Objective-C @ compiler directives in one place. We all know the keywords like @interface and @implementation but others like @dynamic and @encode are lesser known, and possibly even much less understood.
Although I know most of them already, I couldn’t shake the feeling that I may be missing a hidden gem. So I made an effort to document all the Objective-C @ compiler directives in one place.
What do you do if your app doesn’t behave as it should, or even crashes?
Answer A: Post your problem in just about every programming forum.
Answer B: Use the Xcode Debugger to analyze what’s going wrong.
Since most of you already know how to do A I’ll focus on B in this Xcode 4 Debugging Crash-Course. It’s kind of aimed at beginning Xcode developers but that’s just because I hope - against better knowledge - that experienced developers already know that … thing … that debugger stuff. Ya know?
This Kobold2D FAQ article explains the difference between Corona SDK and iPhone Wax library, and evaluates the existing and future options for Lua scripting in Kobold2D.
Recently, I’ve changed all my project’s source code files from .m to .mm file extensions. This is telling the compiler to compile the files as Objective-C++/C++ code instead of the default Objective-C/C. I needed to do so because I’m using Box2D, and as a habit I intend to use .mm from now on for every source file I create.
However, beware the subtle differences. Previously, if an NSAssert was triggered, it halted the program execution. But in .mm files it simply prints the assertion message to the console while the App continues execution. This leads to overlooked assertions, or continuously dumping assertion messages to the console. Clearly not what I wanted. Changing the file extension from .mm back to .m fixed the problem, but that’s not an option I have for all files.
I looked around and found a blog article by Vincent Gable mentioning that NSAssert is considered harmful. That caught my attention, because it described the same problem that I experienced (NSAssert not halting execution) while basing the argument on Voodoo (“Sometimes it does, sometimes it does not …”) respectively no argument at all, it’s just telling you “NSAssert is unreliable, therefore dangerous”.
It’s as if he wants me to prove him wrong. 
In Vincent’s defense, the wrong he’s done unto NSAssert he makes up for by having written a great logging method which I’m going to add to gocos because it’s so handy.
Why assert() is less useful than NSAssert
First of all, the assert() function has one big problem: it doesn’t allow parameters to be added to the output string, since the output string can only be a constant string, like in this example:
[cc lang=”objc”]
assert(value < maxValue && @"value too big!");
[/cc]
With NSAssert you can actually embedd some values into the assertion message:
[cc lang="objc"]
NSAssert2(value < maxValue, @"value %i too big (max:%i)!", value, maxValue);
[/cc]
It is tremendeously helpful in many cases to actually see the offending or interesting values in the error message, without having to fire up the debugger. Especially when it comes to filenames, and even more so if end users might see those assertions. Not a problem on the iOS, but think of developing desktop Apps.
Why NSAssert isn’t harmful, and how to fix it
So then, why did my App not stop execution when an NSAssert triggered? I can’t really answer you that, Apple’s docs say that NSAssert will raise an NSInternalInconsistencyException. So that should stop the App from running? It does not seem to be the case when you’re using the Objective-C++ compiler, and I’m not running the code on a different thread either. Maybe someone can shed some light as to why NSAssert in C++ code doesn’t automatically stop the App from running.
The good thing is, there’s an easy way to fix that. In Xcode choose Run -> Show -> Breakpoints from the menu, to bring up the breakpoints list. In the breakpoint list you only need to add the symbol objc_exception_throw. Next time an NSAssert triggers, the App will stop immediately and bring up the debugger.
Some places (for example: here) will also tell you to add [NSException raise] to the breakpoints list. That’s not necessary, this has been replaced with objc_exception_throw since Mac OS X 10.5.
Turning off assertions
I must admit, I’m totally spoiled by Visual Studio. Why Xcode requires you to add NS_BLOCK_ASSERTIONS as a macro to your project’s build settings in order to not compile NSAssert in release builds is beyond me. If you’re using NSAssert in your code, make sure that your release and/or distribution builds define the NS_BLOCK_ASSERTIONS macro.
If you do use the assert() macro however, or if you’re using a 3rd party library that uses assert(), make sure to also define NDEBUG for release/distribution builds.
As a side note, when I update my cocos2d-project respectively replace it with gocos, it will have all these settings properly configured.
Catching uncaught exceptions
On a related matter, there’s always the issue of uncaught exceptions simply halting your App, with little chance to debug the actual cause. It happens rarely but when it does, it would be really helpful to also bring up the debugger with the current call stack and everything. You can set a global exception handler to catch uncaught exceptions by calling the NSSetUncaughtExceptionHandler in the applicationDidFinishLaunching method of your AppDelegate:
[cc lang=”objc”]
void onUncaughtException(NSException* exception)
{
NSLog(@”uncaught exception: %@”, exception.description);
}
-(void) applicationDidFinishLaunching:(UIApplication*)application
{
NSSetUncaughtExceptionHandler(&onUncaughtException);
…
}
[/cc]
In the onUncaughtException method you’ll simply log the exception and (very important) add a breakpoint. The NSLog message serves the purpose of being able to easily set a breakpoint inside this method. It should not be another NSAssert because that will throw another exception, which will only serve to make debugging more complicated when a simple breakpoint suffices.
