Mac Programmers Take Saturday Off?

Since this is a new blog, I decided to perform a little Technorati search to see if I showed up. Yeah yeah, I know I'm totally being sucked into this whole Silicon Valley culture. Next thing you know, I'll start thumbing through Valley Wag instead of the National Enquirer at the checkout line. But I digress. The point is, I was shamelessly searching for myelf on Technorati, when I came upon this helpful graph:



First off, I'd love to compliment Technorati for using a bar graph instead of the pervasive point connected line graph that is entirely misleading. I'm sure all my zero readers will hear me ranting about this later. Back to the graph, you'll notice a (disturbing?) cycle. Every Saturday there happens to be a sharp dip in the number of blogs containing Mac Programming. However, it stays fairly constant for the rest of the week. I was going to compare this to graphs of Windows, or C++ programmers and make some broad generalizations about how easy Mac development is or how much we love our work, or know how to lead balanced lives. Unfortunately for us all, the Technorati search is not performing properly right now. And, you know what? It's Saturday. I think I'll stop sitting in front of the computer and go do something fun. And you, diligent readers, should do the same.

Cross Platform GUI

http://www.losingfight.com/blog/2006/07/27/survey-of-cross-platform-gui-architectures/

Interesting post about cross platform gui development. As someone who is currently developing mac software, perhaps unsurprisingly, my thoughts are similar to Mr. Finnell's. I feel that in order to create the best user experience on each platform you develop for, the GUI must be done natively in order to take full advantage of all that the platform has to offer. Although it most likely increases total development time, the end result is a better product.

The Joys Of Threading

One of the wonderful things about Cocoa is that it performs so much of the heavy lifting for so many mundane tasks. This is great if you can do everything you want to from within the confines of Cocoa. Unfortunately, this is not always possible. Continuing on my Objective-C++ vector, I want to remind you that if you have C++ code that is doing anything interesting, spawning threads for example, you may need to do some of the heavy lifting yourself. As it turned out, I needed a NSRunLoop to exist in one of my C++ spawned threads. I only discovered this through some helpful hints on Apple Developer Mailing Lists. Although in my case it turned out to be a relatively easy fix (creating a NSRunLoop at the beginning of my C++ spawned thread), it's a good thing to keep in mind that when mixing languages, not all constructs are created equal.

Subjective-C++

Why do I feel the need to have a witty title just because this is a blog? I feel like I'm being sucked into this whole blogging hell hole. I hate it, but I feel compelled to do it by the desire to vent my frustrations someplace other than my coworkers who I'm sure are quite sick of it.

Getting back on track, the subject of this post is Objective-C++. There is precious little literature available on the topic. The example code on Apple's site is from 2003 and does nothing of any use other than show you the proper file extension needed to compile Objective-C++ code. And the Objective-C++ section in the Objective-C manual is minimal.

The biggest resource I've found for Objective-C++ is WebKit, which is thankfully open source. I learned this through an ObjC mailing list via a helpful pointer from Michael Ash. Perusing through the source was invaluable to the work I am doing. I thought I'd start off by sharing some tips on wrapping C++ objects in Objective-C.

One thing you might want to do if you're mixing C++ and Objective-C is wrap your C++ objects so that the rest of your Cocoa app can use them without changing everything to a .mm file. Now this ObjC object will need to contain a pointer to your C++ object and your header will look something like this.

#include "CppClass.h"

@interface ObjCWrapper : NSObject {
 CppClass *m_cppObject;
}
- (CppClass*)cppObject;
- (id)wrapperMethod;
...
@end

As you might have noticed, if you try to include this in an Objective-C file, the compiler will yell at you and you might start pulling all your hair out (which may or may not have happened to me) thinking it might be impossible to have a clean separation of programming languages. Well after digging through the WebKit code, I came across several headers that had something like this in place of the #include.

#ifdef __cplusplus
class CppClass;
#else
@class CppClass;
#endif

What we're doing is forward declaring the class which is great since we don't have to include the C++ header file. But what's counter-intuitive is that if this file gets included in an Objective-C file, the CppClass is forward declared as an Objective-C class. I suppose the reason that this is ok that you only reference the CppClass from within your wrapper class. As long as you don't try to use the object from within pure Objective-C code, you'll be golden.