Objective-C and C++

CodFusion [via James Robertson]: "Can Adobe just port what they have into Objective-C or use Carbon. Unfortunately no, the Flash Player is written in C++ and going from C++ to Objective-C is not very practical. Objective-C is just another superset of C. It simply adds some OOP logic and a messaging and some of the syntax is similar to Smalltalk. You can compile any C program into Objective-C but that's not currently possible to do with a C++ program." - Emphasis is mine. I can assure you, having done it myself, you can use your current C++ code from Objective-C. I took a collection of pure C++ classes, unmodified, and used them from an Object-C/Cocoa based application. That collection of classes did not have any OS specific code, which made my job easier.

That's not to say Adobe doesn't face a huge uphill climb, it really does, but it can be done. Replacing Carbon with Cocoa is going to be tough. Since they're a cross platform shop I would hope they have a nice set of frameworks that abstract most of the platform specifics from the developer, but that of course is difficult to do. The Photoshop team is in the middle of the Carbon to Cocoa battle.

Bottom line - you can use your C++ with your Objective-C code.

P.S. - I have become a huge fan of Objective-C and Cocoa, I'm just sayin'.

Labels: , , , ,

Posted by Rob at 8:26 AM | 0 comments | Click here for a permalink to this entry.

Breaking on a memory allocation

I keep forgetting to write this down, so it's going on the good ole weblog for searching later.

If you have your code setup to do heap allocation tracking, _CTRDBG_LEAK_CHECK_DF and you'd like to break on a specific allocation, here's what you do once you've started debugging.

Add the following to the watch window.


Set the value to the allocation you'd like to break on. Now, if you're using the multi-threaded DLL runtime you'll have to provide a better context to the debugger. Like this.


So, if I'd like to see who allocated a hunk of memory, they were the 1000th caller, and they didn't free said memory, set the value to 1000, and the debugger will stop on allocation 1000.

Handy, big time handy.

Article on MSDN with more details, How to: Set Breakpoints on a Memory Allocation Number.

Labels: , , , , , ,

Posted by Rob at 1:48 PM | 0 comments | Click here for a permalink to this entry.

Coding for the iPhone

I've been working on my iPhone application again, it's been months, and I've been making good progress. Cocoa Touch and Objective-C are beginning to slowly sink into my thick skull, which is a very good thing. I have a bunch of experiences to share and I really need to sit down and write them up, with hopes is helps another poor Win32/C++/COM guy make the leap into Cocoa/Objective-C land.

Duct Tape, fixer of all things!What are some of the things I hope to talk about? Glad you asked. The application I'm working on is very table oriented. It's really about data collection, so I've formed some very good patterns for dealing with it. Another thing I'd like to address is my view of reference counting with Cocoa, from a COM developers perspective. I'd also like to dive into is comparing Win32/C++/COM to Objective-C/Cocoa to .NET/C#/pick a language. I think Apple used to have a leg up with Objective-C/Cocoa, now I honestly believe .NET may have the edge in the rapid development department.

Hopefully I'll get around to writing about it some day, but you never know, this tease may be the final word.

As of this writing it's still my goal to become a full time Objective-C/Cocoa/Mac/iPhone developer, that's how much I'm enjoying the experience.

Labels: , , , , , , , ,

Posted by Rob at 9:38 AM | 0 comments | Click here for a permalink to this entry.

Plugging C into Python

Ned Batchelder: "Python can be extended with extensions written in C. It's a complex topic, this will be a quick 45 minute introduction." - If you've ever wanted to hookup some good old fashioned C code to your Python application, this is a great starting point. Thanks Ned.

Labels: , , ,

Posted by Rob at 5:37 AM | 0 comments | Click here for a permalink to this entry.

What to live in South Dakota?

jobs.joelonsoftware.com: "Rather than looking for experience with a specific technology, we're looking for people with the proven ability to learn what they need to accomplish the task at hand. Right now we use Python, PostgreSQL, MS SQL Server, Django, Javascript, C++, Qt, and .NET (C#), among other things, but this is always changing."

Labels: , , , , , ,

Posted by Rob at 9:46 PM | 0 comments | Click here for a permalink to this entry.

More Visual Studio 2008 ick

I love Visual Studio. I need a little badge I can wear around that says "I (heart) Visual Studio!" I do, I really, really do. But... and there's always a but isn't there?

The latest release seems to have really gone the wrong direction for the C/C++ developer, in my humble opinion. Editing, debugging, all great. The problem seems to lie in the auto completion/browsing capability. It's horribly slow. This morning, after 30-minutes, I finally had to kill off Visual Studio after right-clicking so I could "Go to Definition" of a method. Yes, I had other stuff to do so I left it alone hoping to come back and the hour glass disappear so I could work, no luck. Nuke it.

So, here I sit, waiting on a build to complete, and I make the mistake of right clicking on method name again. The IDE is now out to lunch, sorry Rob, no right mouse clicks for you, and you can forget ever seeing that menu you'd like to see.

Thing is I'll bet the C#, and Visual Basic crowd, are pretty pleased with it. All those nice little pop-up tool-tippy style helpers that allow you to dig into objects to inspect their values is pretty darned nice. Too bad it comes at the expense of the C/C++ side of the equation.

Maybe, just maybe, there are some settings I'm not aware of that will allow me to get better responsiveness from the bits I do like? I'll need to dig around and see if I can turn off some stuff to improve performance.

PS, I wonder, if the DNA of Visual Studio has a built in defense mechanism that causes it to misbehave in a VM on a Mac? It could happen...

PPS, it's still better than Vi, emacs, and gdb on Linux. Heaven forbid I have to work in that all day, every day.

PPPS, Note to the Linux world. Check out the great job the XCode guys did on their IDE. It uses gdb under the hood and allows you different views of the debugger, gdb console view and a nice GUI view that allows you to set breakpoints interactively.

PPPPS, I need to look at KDevelop again. Maybe it's much better than I give it credit for.

Labels: , , ,

Posted by Rob at 8:49 AM | 1 comments | Click here for a permalink to this entry.

Job of the week

jobs.joelonsoftware.com: "Sony Computer Entertainment America Inc. (SCEA) markets the PlayStation® family of products and develops, publishes, markets, and distributes software for the PlayStation®Portable entertainment system, PlayStation®2 and PlayStation®3 computer entertainment systems, for the North American market." - I'll bet it's a very tough place to work, but rewarding.

Labels: , , , , , ,

Posted by Rob at 10:24 AM | 0 comments | Click here for a permalink to this entry.

iPhone experimentation continues

I've been exploring the iPhone SDK lately, it's been fun. I've finally figured some stuff out so it's really starting to get exciting. My "big" hurdle had been understanding how to take advantage of Interface Builder. I finally figured out how to hookup events now that seems pretty obvious, I knew that would happen, light bulb on, bing!

Here's a question for any Mac developers. Do people actually use the Interface Builder to design visually and hookup events, or do they draw the interface and hookup events in code, or do they build the UI all in code? I know, it's a strange question, and I'm sure I'll get a strange mix of answers, if any at all, but I had to ask. I'd love for Daniel Jalkut, or Brent Simmons to chime in.

Doing Windows C/C++ stuff for years had led to a certain expectation with Mac tools. In Windows I only used the graphical tools to create dialogs (at Visio we didn't even do that), then I'd go hook up event handlers in code. It was very straight forward and after using Interface Builder once I can see how easy it would be to hookup events in code instead of letting Interface Builder generate code for me.

I was very happy to discover a hunk of old C++ code compiled and worked like a charm when mixed with Objective-C. It was a pharmacokinetics library my brother and I created a long time back, and it just built and worked. That is a HUGE leg up for me. I can use my bad habit of writing C++ and slowly move into Objective-C. Very nice.

Next hurdle, gaining a better understanding of Objective-C.

It sure would be nice to build a Cocoa version of the Endura WS5000 software, hint, hint.

Labels: , , , , , ,

Posted by Rob at 9:12 AM | 4 comments | Click here for a permalink to this entry.

New C++ performance weblog

Chris Cox [via John Nack]: "A few weeks ago, I sent the initial release out to select compiler vendors for review. I received responses from 3 of the major compiler vendors, and 2 compiler teams have already found and fixed a couple of bugs based on my code (Yea!)." - Nice new find, thanks John. Subscribed.

Labels: , ,

Posted by Rob at 6:48 AM | 0 comments | Click here for a permalink to this entry.


Rob Fahrni has been a Software Developer for 20 years. He's developed DOS, Windows, Linux, iPhone, and Palm based applications in C, C++, Objective-C/Cocoa, C#/ASP.Net, and, yes, even BASIC...
About >>

CrabApples.NET Home Kim Fahrni, Hacker Widow Haileigh Fahrni, My Culinary Journey Taylor Fahrni, Goin' Buggy Jerry Fahrni, Pharmacy Informatics and Technology

Apple Core Labs, LLC RxCalc - A Pharmacokinetic Calculator for iPhone


I work at Pelco. The opinions expressed here are my own, and neither Pelco nor any other party necessarily agrees with them.

Subscribe to ATC Send e-mail to Rob Follow me on Twitter. My Profile on LinkedIn.