Last year, I presented an approach to wrapping C++. Since then, I’ve been introduced to other approaches, particularly from gf who helped me better understand opaque objects. Since I do a lot of cross-language work, I’ve had some opportunity to play with and expand this, and so I’d like to update my C++ wrapping approach.
First, to remind everyone of the problem: you have a C++ object that you want to consume in Objective-C. That’s easy in ObjC++, but if you make an ivar that references a C++ class, then the header file can only be included by ObjC++ classes. This quickly spreads .mm files throughout your project, creating all kinds of headaches. ObjC is a beautiful thing, and C++ is fine, but ObjC++ is a crazy land that should be carefully segregated from civilized code. So how do we do it?
Read more…
See Take 2 for an updated approach to this problem.
When faced with mixing C++ and ObjC code, there are two main approaches. One is to just work in Objective-C++ through the entire project. I don’t like this approach. I find the mixing of ObjC and C++ classes very confusing, since they cannot be used interchangeably and require completely different memory management. The mix of class hierarchies and naming conventions lead to a lot of confusion when we introduce people to code that does this kind of mixing.
My opinion is that ObjC and C++ have very different patterns, so it is important to pick one to be in charge and wrap the other. So if you basically have an C++ program than needs a little ObjC to talk to the UI, then wrap the ObjC in C++ objects. If you basically have an ObjC program that needs a C++ middleware, then wrap the C++ objects. Read more…
I’ll talk more about it later, but the absolute best way to learn iPhone is to learn Mac first. That’s how I teach my classes. The available Mac educational resources are just much better, at least today.
The absolute gold standard for learning Cocoa on Mac is Cocoa Programming for Mac OS X
by Aaron Hillegass. It is the book. I have a syllabus based on it that’s stripped down to the chapters that are useful for iPhone programmers. I’ll get that into a blog post.
When I teach this, it runs between 5 and 10 full days depending on how in-depth I cover the Mac side. Read more…
Have I mentioned recently how much I love Cocoa? Even when I hate Cocoa, I love working in it. And things that drive me nuts (like the lack of regexes) come along in due course (Leopard). I was listening to CocoaRadio today and there was a comment along these lines. Cocoa has been evolving for about 20 years now. Much of the core is carried over from NeXT. But rather than “showing its age” it keeps showing its wisdom, and those early guys thought it out well enough that Apple hasn’t had to start over again and again as Windows has with Win32 to MFC/WTL to .NET. For how unusual Objective-C is, it’s a constant rather than moving between C, C++, C#, and Java as the winds blow. (And the more I program in Objective-C, the more I enjoy it.)
Tonight I added a station-changing menu to PandoraBoy. There’s still a lot to add to make it really useful (hotkey support and Applescript at least), but the core’s there, and it wasn’t hard. It forced me to simplify a slight duplication in the object model (PandoraControl and Controller were doing almost exactly the same work so I’ve merged them). That cleaned up a lot of redundant code. Even after merging the two objects, Controller is under 400 lines of code, so I don’t think I need to worry about splitting Controller back up some other way.
