Porting C++ code to Objective-C

I’m in the middle of porting a Windows C++ application to the mac.  I’ve posted before that I was pleasantly pleased to find that with some limitations, XCode supports mixing C++ and objective-C code.

Here are a few things to look out for when working with C++ code in a Cocoa application:

1. Missing C++ member functions may not be flagged at compile time and your program will abort with a message similar to:

ZeroLink: unknown symbol ‘__ZN8DVFArray6ExistsEP6DVFObj’

You can use the C++filt program which is part of the GNU Binary Utilities to help demangle the function in error.  I could not build this package so I looked and found a copy of the C++filt program. Unfortunately I could only find a copy for the PC.
The example listed demangles to: DVFArray::Exists(DVFObj*)

2. You cannot store C++ objects/pointers in Cocoa containers.  One workaround is to store NSValue objects in the containers and store C++ pointeres in the NSValue objects:

[myNSArray addObject:[NSValue valueWithPointer:pCPPObj]];
.
.
pCPPObj = [[_array objectAtIndex:idx] pointerValue]

3. You should not use static C++ objects or static data members.  Constructors for static objects will be called before main() is called and you will not have an NSAutoReleasePool initialized yet. You will get a message similar to:

*** _NSAutoreleaseNoPool(): Object 0×307f60 of class NSConcreteValue autoreleased with no pool in place – just leaking

The discussion "NSAutoreleasePool and static data member constructors" is very good on this subject

Pixen: A Free image editor for Mac

I am using Pixen for image editing on the Mac.  Like others that have written, I was surprised that no such program was included in the Mac OS.  I’ve just barely started using it but it so far it does what I need.  I was particularly impressed with the getting started wizard that took you through an overview of the program and  allowed you to set some program settings at the same time!  I model of what all programs should offer.  The only think I would recommend is showing a Page X of Y on each wizard page to let the user know how long it is.

Update:  Paintbrush is a nice alternative that emulates the Windows Paint program

EXC_BAD_ACCESS during startup

Once again, the XCODE debugger not only failed to help but got in the way by showing me a stack trace that was not directly relevant to my problem.   The program crashed with EXC_BAD_ACCESS and the stack trace looked like this:

#0    0×90a594c7 in objc_msgSend
#1    0xbffff7b8 in ??
#2    0×932899d8 in loadNib
#3    0×932893d9 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:]
#4    0×9328903a in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:]
#5    0×93288f7c in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#6    0×93288cc3 in NSApplicationMain
#7    0×00009f80 in main at main.mm:17

This made me think that my NIB was corrupt since I didn’t see anything in the stack trace that pointed to my code. After wasting several hours investigating that rat hole, I decided to try to do what the debugger didn’t help with and that’s track down the offending line.  With breakpoints and Debugger(); calls (breakpoints don’t always work for me) I found that an IBOutlet was not being initialized and I was sending a message to nil.  If the run-time was not going to flag this as an error, why would this cause a problem down the line?  Arrggg! 

Lesson learned, if a stack trace looks similar to the above, then look at your initialization code of your Nib objects.

Memory bugs in Cocoa

At work, our software runs on Windows and Mac OS.  I’m trying to reuse as much code as possible; not through some fancy cross-platform tools but by simply writing in portable C or C++ code and by using class wrappers that can each be implemented in the native platform.  One thing I’ve been pretty pleased with XCode is it’s support of mixing Objective-C and C++ code fairly seamlessly.

Recently, in trying to port some C++ Windows code over I started having some memory crashes.  Unfortunately the XCode debugger was of very little help with the stack trace not including any calls from my code.  This was an excellent thread on some techniques to troubleshoot EXC_BAD_ACCESS problems.  Fortunately, I didn’t have to try all the various techniques listed.  After reading the entire thread I decided to pursue the notion that I might be over-releasing an object (though why should this be a problem?  A warning perhaps but seems once a reference counter is down to 0 calling release again should be harmless).  This DID lead me to the offending code so I was able to fix my problem without wasting too much time.  Once again, the developer community saved me hours if not days of debugging.  How did we get along as programmers before the Web?

Debugging AutoRelease problems