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'.
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.
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.
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.
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.